Introduce dedicated node to store markup

Introduce dedicated node to store markup

Summary:
Previously we used to parse markup as a trivia which is inconvenient for a several reasons:
- markup is emitted during codegen which means that it should preserve its position relative to other source elements. Also position-based representation the tree loses information about trivia kinds so when at some point we need markup we need to repeat all the work that was already done by parser before.
- script section that starts with `<?=` short tag should contain only expressions or expression statements, declarations and other kinds of statements are not legal there (because content of this section is treated as if it is passed as an argument to `echo` function).

In the code markup can appear at positions where statements are permitted so for our purposes we can treat markup as a special kind of statement that starts with optional `?>` tag followed by arbitrary text that is not `<?` and ends with optional `<?` followed by the identifier (like `php` or `hh` possibly with different casing) or `=` for `<?=` tag, something like this:

```lang=ocaml
type script_section =
{  prefix: Token option
;  text: string
;  expression: expr option
;  suffix: script_suffix }

type script_suffix =
{  less_than_question: Token
;  name: Token }
```

`expression` in `script_section` represents expression statement that starts with `<?=` - this structure makes it very convenient to deal with such expressions on later steps. Alternative will be to treat this expression statement as a sibling of a markup section but then in order to determine if script section is permitted to have declarations or to emit the code we'll need to pull in previous statement to check if it was markup that ends with `<?=` - step which is quite invasive for a existing codebase and that is very easy to miss in a new code.

*NOTE*: since this change alters the structure of the tree it touches pretty much all ffp baselines. Adding ~700 files more to this diff (which is already large) will make it impossible to digest so at this point in case if test finishes *successfully* I'm patching its output to adapt it to a previous shape of the tree. Updating all test baselines will be sent as a separate diff.

Reviewed By: ericlippert

Differential Revision: D5277354

fbshipit-source-id: e56ebaaaef6551d6877fba6b79a79d1f41c1d156