Add basic support for parsing and generating heredocs

[apiology]

Without this change, the data lines in a heredoc are not generated, resulting in a syntax error in the generated RBI:

FOO = <<EOF
bar
EOF

becomes just

FOO = <<EOF

[apiology]

CLA just signed

[Morriar]

Hi @apiology,

Thank you for your contribution but I do not believe this is the right fix.

It looks like the problem stems from the location Prism returns for an heredoc.

Consider this snippet:

require "prism"

ruby_string = <<~RUBY
  FOO = <<~EOF
    foo
  EOF
RUBY

puts Prism.parse(ruby_string).inspect

Prism will return the following AST:

#<Prism::ParseResult:0x000000011f9556f8 @value=@ ProgramNode (location: (1,0)-(1,12))
├── flags: ∅
├── locals: []
└── statements:
    @ StatementsNode (location: (1,0)-(1,12))
    ├── flags: ∅
    └── body: (length: 1)
        └── @ ConstantWriteNode (location: (1,0)-(1,12))
            ├── flags: newline
            ├── name: :FOO
            ├── name_loc: (1,0)-(1,3) = "FOO"
            ├── value:
            │   @ StringNode (location: (1,6)-(1,12))
            │   ├── flags: ∅
            │   ├── opening_loc: (1,6)-(1,12) = "<<~EOF"
            │   ├── content_loc: (2,0)-(3,0) = "  foo\n"
            │   ├── closing_loc: (3,0)-(4,0) = "EOF\n"
            │   └── unescaped: "foo\n"
            └── operator_loc: (1,4)-(1,5) = "="

Note how the closing_loc points to the correct location at the end of the EOF marker yet the node location (@ StringNode (location: (1,6)-(1,12))) only includes the opening marker.

Digging a bit in Prism issues, I found ruby/prism#1260 explaining this behavior is actually desirable.

Given this, I think the best way is to adjust the Prism location when we encounter a constant that holds a heredoc value. I opened #408 that should solve your issue. Could you confirm for me please?