JS: consider using web components over Knockout

With the work that we've been doing on addons with web components, I'm slightly motivated to use web components on the new dashboard eventually. The goal would be to eventually remove Knockout from our stack.

A couple points on technical implementation:

• Knockout doesn't play great with ES class structures
• We're using Knockout almost exclusively for two way data binding -- updates to the underlying modeling update the DOM automatically. Web components also gives us this.
• Knockout isn't well maintained and TKO is probably never going to gain serious adoption with other modern options available
• Vue is fairly synonymous with Knockout, it just has more attention these days. I'm sure that will change at some point as well though
• We probably have more shared understanding of web components now than Knockout
• We wouldn't need to use the web component CSS styles, these are all classes in SUI

I'm not entirely sure of how the actual work here might proceed though. I suspect we'd have a mix of Knockout/web components for a short while. There are some views that would translate easily. There are also some views that would require some more thought -- mostly views with nested views like model listing pages.

Either way, it wouldn't be something to jump deep into, but instead take on the additional dependencies (Lit) and try this pattern out on new elements. We'd have a period where our bundle would be a bit inflated with Lit and Knockout (though luckily both are relatively small libraries). This would likely happen after moving out of a beta period.

If we are interested in consolidating on web components, this could be a path forward.

Pinging @humitos as you've had experience with both. I'd be curious to know what you think and what you feel your experience is on both of these libraries.

Start by reviewing the new dashboard, existing Knockout views, and the addon work using web components. Compare the proposed Lit/web-component approach with the current two-way binding patterns, then define a small pilot and an agreed migration path before attempting broader replacement.