Better support and indicators in HBS with JS Backing Files

[rtablada]

Currently when working with an HBS file with JS backing file, Glint (and/or broader Ember language server tooling) seems to turn itself off entirely. This means components and helpers with known types and even primitive values are untyped and unchecked. An HBS file can go from fully type checked when it has no backing class to ignored and little to no language server aid. That's a confusing and jarring user experience and not really apparent that this is going on.

Since HBS is a roughly a static AST with roughly independent parts, even templates with heavy use of this or untyped block yielded values should have fairly large chunks of type checkable and language server supported statements.

In HBS files with backing JS files we can use a similar approach to template only components for statements where there aren't references to this or unknown yield values. We can/should keep type references for component/helper use and only abort/give up for statements that explicitly use non typed or literal values.

I have created a small new project with Glint here and have a few example files:

1. UsesTs declaration of the component type/signature
2. eq a simple helper with boolean return type to what is shown for the variable type (or if it is even shown as a variable that could have a type
3. a.hbs an example HBS component with backing TS file which is properly checked and notes missing/invalid arguments and has useful language server hints for the eq helper return type
4. b.hbs an example HBS component with backing JS file has no checks for UseTs signature nor language server hints for the eq helper return type
5. c.gts an example GTS component which is properly checked and notes missing/invalid arguments and has useful language server hints for the eq helper return type
6. d.gjs an example GJS component and has no checks for UseTs signature nor language server hints for the eq helper return type

In all of these examples the template is fully declared using registry components/helpers and string literals and should be type-able regardless of the JS backing class

[rtablada]

Since HBS is a more deterministic AST than a scripting language. I think there's also room to investigate breaking apart JS backed templates and doing type/language server support on nodes and trees that work with typed components/helpers/functions and literal values (ie, don't use this or yielded blocks from untyped components).

For example given the template:

{{#let this.message as |message|}}
  <p>{{message}}</p>
{{/let}}

<ComponentInRegistry 
  @stringArg="string value"
  @numArg={{2}} 
  @boolArg={{false}} 
  @someArg={{eq "string value" "another string value"}} />

The let block is not easily typed in a JS backed template due to use of this. But the entire ComponentInRegistry invocation is using values with literals and could be supported.

---

Something as an alternative to breaking into discernible vs unknown statements is that we could generate a fake backing .d.ts file that pretends like any types used that can't be calculated from literals or registry values. That feels a bit overzealous but in reality is no worse than the current state of someone using HBS files with a backing JS class and having no type help.