Have plugins use core-determined language identifiers

[cmyr]

Our use of the syntect plugin for syntax highlighting predates the existence of language identifiers in core. The syntect plugin current determines the syntax to use based on the path of the file, and updates it when the file has changed.

This is now redundant. Instead, the language identifier that is assigned in core (which may be guesed from the filename or the file's first line, or may be overridden by a user) should be the sole/canonical source of truth.

This means that:

• when a new document is opened, the LanguageId should be included in the set of info we send the plugin.
• when the LanguageId changes in core, we should update the plugin (and the client) similarly to how we do currently when a config changes. This probably means adding a new core->plugin RPC; I could one day imagining combining these into a per-buffer 'metadata' RPC, but for now separate is fine.
• the syntect plugin should no longer guess the LanguageId on its own; it should use what is provided by the core.

There are still some kind of weird things related to languages and configs. For instance, there should be a config setting that allows the user to specify which language to assign to files, based on their extension; and so this config, when changed, could potentially change the language of an open file, which would cause it to update its config.

It also isn't clear how, long-term, we're going to manage plugin lifecycle, but we may end up doing something like #374, which might require changing how we tell plugins about language changes, but I think this change is reasonable for now.

[akxcv]

The checklist you've outlined looks good! I'll be taking this on as discussed on IRC.