Feature Request: Add method to dynamically register scripts with light client SPK index

I think the use case is pretty general, so it's partly a sanity check whether I'm missing a way to do it: how to add an arbitrary script to bdk_kyoto's subscription to scriptPubKeys, rather than be limited to a script coming from a BIP32 derivation.
I could imagine it being useful in various semi-L2 or L2 protocols or privacy protocols.

It goes without saying that this scenario (wallets controlling keys that are not part of an HD tree) has been "out of fashion" for more than a decade, it's far from standard/normal, but that's a lot different than saying it's unnecessary or useless, I'd claim. I'm not sure how it works with multisig, e.g. in 2/2 wallets with lightning or inheritance etc. but I guess that's somewhat different due to there being a kind of compounding of inheritance of multiple HD trees.

But being specific is probably required, so here you go: specifically, my actual use-case: I'm implementing a https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79 wallet using
bdk_wallet and bdk_kyoto. SNICKER is basically a non-interactive coinjoin where the trick is to pay to a tweaked version of someone's existing pubkey. Since these tweaks are derived without the interaction of the receiver (using non-interactive ECDH), it's not possible to avoid having these be something new to the receiver; they have to dynamically add this scriptpubkey to their watch list when they receive the proposal to coinjoin and agree to receive funds at that tweaked address [1].

My implementation is currently p2tr specific, but I guess this enhancement request isn't.

From my reading, we basically are going to subscribe to scripts using `UpdateSubscriber` but this does not support any public API to add a new script outside the HD tree, right? So I would imagine (and in fact have tried using) a patch that adds a public method like:

```
pub fn add_script(&mut self, script: ScriptBuf) {
self.spk_cache.insert(script);
}
```

... except that, to state the obvious, there's bound to be second order effects/implications I'm unaware of.

[1] You're probably thinking that, oh, if you have a wallet with nonstandard/non-derived outputs, you're going to have a lot more problems than just with filters, using bdk_wallet. That's true, but I think I can handle the other stuff by basically hybridising and adding maintenance of these other utxos as an add-on but keeping the existing handling of the HD tree utxos (it's a whole can of worms, but I know how to deal with it).

Start by reading UpdateSubscriber and tracing how the spk_cache is populated and used for scriptPubKey subscriptions. Evaluate the proposed public add_script entry point and its effects on tracking arbitrary scripts, including the stated P2TR use case. Done means a supported API can register a non-derived script and the light client observes it correctly, with relevant coverage added if the existing structure permits.

Written by the indexing model from the issue text.