Re-wire how we manage LSP Requests

[Matsuuu]

So currently when we are asking for e.g. QuickInfo, we are getting the LanguageService instance on the server side and then asking it for getQuickInfoAtPosition. This however only works for template literal parts and not for e.g. HTML files.

The new approach should be:

graph TD;
    Client-->Server
    -->Choice1{Is Template Literal?}
    Choice1--Yes-->Go-to-Language-Service
    Choice1--No-->Go-Straight-to-Implementation

What this would mean for the implementation side would be to make the handlers stored in the html-template-literal-tsserver-plugin not rely on the context: TemplateContext object as that is only acquired through the Language Service approach. The information it holds, however can be accessed by other means most, if not all of the time.

How I would invision the response system to work in the Future would be:

graph TD;
    Client-->Server
    -->server.ts
    -->handlers/action-name.ts
    -->Check1{Is JS/TS file?}
    Check1--Yes-->handlers/action-name.ts:handleJS
    Check1--No-->handlers/action-name.ts:handleOther
    handlers/action-name.ts:handleJS-->GetLanguageServiceInstance-->CallLanguageService
    -->CreateNeededDataFromContext-->CreateActionContext
    handlers/action-name.ts:handleOther-->GetHTMLLanguageService-->CreateNeededDataFromHTMLAnalysis-->CreateActionContext
    CreateActionContext-->CallActualHandler
    -->ReturnResults
    -->TransformResults

With this refactor, we should get a cleaner server.ts -file and also a good, clear separation of concerns for stuff.

Some things to consider while we're at it:

• Do we need an abstract class to extend to create these handlers? Would make them follow the same protocol
• Should we rename the plugin package to something else since the name html-template-literal-tsserver-plugin doesn't really fit here. Something like custom-elements-language-services
• Other?