(How) should we integrate the native Signals proposal

I brought this up in #67, and want to make sure the consideration survives that being merged.

Somewhat in tandem with the work in that PR, there has been some renewed interest in [standardizing reactive Signals](https://github.com/tc39/proposal-signals). In fact, the proposal just moved to TC-39 Stage 1 (yesterday I believe). This isn't a firm guarantee that the proposal is going to become a standard, but this step happened relatively quite quickly, which is a strong (ahem) signal that there is strong interest in moving it in that direction.

I think we should track this for a variety of reasons. At minimum, a Signals standard would likely be an integration target for the engine's client interface. In the last few years, the (lowercase-s) signals abstraction has spread like figurative wildfire throughout almost[^1] the entire mainstream frontend ecosystem (largely from outside that mainstream where it had already been gathering so much momentum). This new standardization effort is a direct response to this near total convergence. It's reasonable to expect that at some point _it will be assumed_ that most frontend web software with an actively maintained integration API will have some accommodation for Signals.

Other considerations:

- #67 introduces a relatively minimal _internal_ reactivity implementation for testing purposes, and it might be beneficial to orient that implementation around the standard (eventually being able to dispense with some or all of it).
- We currently use Solid's reactivity implementation for many aspects of the engine's implementation of XForms semantics and computational logic. Some notes in #67's aforementioned _internal_ reactivity implementation discuss the possibility that we may some day want to expand and use **that** for such implementation details. But a Signals standard might be another great option. Note that I'm not in any rush to replace this use of Solid reactivity (if ever!), and I've generally found it's a great fit pretty much everywhere we're using it. But I also recognize that #67 is the product of, among other things, some discomfort with the prospect of our using multiple "frontend frameworks". While I think those changes and the client-agnostic interface they realize temper that concern, I also recognize that some of that discomfort has been specifically expressed about similar internal reactive logic using Solid's APIs.
- The standardization effort provides a polyfill (as such standards proposals tend to), itself based on [Angular Signals](https://angular.io/guide/signals)[^2]. Angular's implementation of the abstraction is relatively recent, and another data point in the ecosystem's wildfire-like convergence. At least to me, it would be very appealing to have an integration story that addresses both a forthcoming and likely high-demand web standard **as well** as a framework we've thus far prioritized lower (if at all?), but nonetheless has significant usage and mind share. It's also probably worth mentioning that, also in tandem, Google [announced](https://blog.angular.io/angular-and-wiz-are-better-together-91e633d8cd5a) intent to merge its two most prominent web frameworks—Angular, and its internal Wiz (which is used for most of Google's largest properties).

[^1]: Perhaps ironically, in the mainstream only React has resisted it. Although from what I understand, React's work on an optimizing compiler is expected to produce effectively similar behavior.

[^2]: And as I understand it, with almost no changes from upstream which is kind of 🤯

Start by reading issue #67 and the linked TC39 Signals proposal, then review the existing Solid reactivity usage and the internal reactivity implementation discussed there. Done would be a decided integration direction and an agreed plan for how Signals should relate to the engine’s client interface and internal reactive logic.

Written by the indexing model from the issue text.