VsTextLines has been revised to never be null.

It's not clear to me why this was only using an 'as' cast to convert the docData to an IVsTextLines. We had a hard cast to IVsTextBuffer a line later, and although it's possible that somebody could implement IVsTextBuffer but not IVsTextLines, I can't think of any reasonable scenario for that. Worse off, the only objects here that can be passed to GetDocumentBuffer and actually work would be the editor implementations anyways which would implement all the interfaces.

I'm figuring this all just evolved this way for no good reason, so I'm cleaning it up.

@davkean The AbtractHostObject stuff would all have been the fake IVsHierarchies you used to create for each target; that's all gone now right? I imagine we can delete this hack entirely.

❔ Where would the previous implementation have thrown if this invariant was violated?

Calling the VS API with an empty file path wouldn't have worked, that much is certain.

❔ How do we know FilePath is not null here? Is there already validation of this condition earlier in the code path?

Ditto: code never could have worked prior. And more practically, remote files are backed by the file system in a certain magic temp directory.