Decouple sub language services with top-level MetadataStore

[octref]

Motivation

Currently, html language services use the javascript language service by directly including an instance of the latter. However, for issues such as #130, this would require an instance of CSS LS in HTML, and the vice versa. These dependencies make each LS inter-dependent and hard to understand.

With #800, we can also have a top-level document MetadataSore that consumes FileService and provide up-to-date metadata that's generated from a particular language service, for example:

• File change happens on a file's style region
• CSS LS re-parses style region
• All class names are stored under css.classes for that file

Later the user triggers html class completion

• HTML LS determines it's a class name completion request
• metadataStore.getMetadata(doc.uri)["css.classes"] will have the relevant data
• Use those data to generate completions

Another place that can be simplified is the current findComponents, which provides component intellisense based on the shape of each of the depended components.

Benefits

• Generation of metadata is event-based instead of LSP-feature triggered. This will likely make processing LSP feature faster since some parsing work will have been finished during the language feature request timeframe.
• Less coupling of language services
• Will help Type checking for template expressions #681's overall structure

[octref]

Already done and used in Vetur's completion.