Provide better error recovery when we encounter merge markers in the source.

Provide better error recovery when we encounter merge markers in the source.
    
    Previously we would just treat each merge marker as trivia and then continue
    scanning and parsing like normal.  This worked well in some scenarios, but
    fell down in others like:
    
    ```
    class C {
        public foo() {
    <<<<<<< HEAD
            this.bar();
        }
    =======
            this.baz();
        }
    >>>>>>> Branch
    
        public bar() { }
    }
    ```
    
    The problem stems from the previous approach trying to incorporate both branches of the merge into
    the final tree.  In a case like this, that approach breaks down entirely.  The the parser ends up
    seeing the close curly in both included sections, and it considers the class finished.  Then, it
    starts erroring when it encounters "public bar()".
    
    The fix is to only incorporate one of these sections into the tree.  Specifically, we only include
    the first section.  The second sectoin is treated like trivia and does not affect the parse at all.
    To make the experience more pleasant we do *lexically* classify the second section.  That way it
    does not appear as just plain black text in the editor.  Instead, it will have appropriate lexicla
    classifications for keywords, literals, comments, operators, punctuation, etc.  However, any syntactic
    or semantic feature will not work in the second block due to this being trivia as far as any feature
    is concerned.
    
    This experience is still much better than what we had originally (where merge markers would absolutely)
    destroy the parse tree.  And it is better than what we checked in last week, which could easily create
    a borked tree for many types of merges.
    
    Now, almost all merges should still leave the tree in good shape.  All LS features will work in the
    first section, and lexical classification will work in the second.
Will comment.  

We want hte end marker treated as an individual piece of trivia.  That makes later parts of the pipeline much simpler.  For example, when classifying, we don't need to recompute which piece is the end marker.  it just shows up for us in the token stream.