refactor: splicer WIT and generated bindings

[vados-cosmonic]

This commit refactors the WIT for the splicer, and moves the generated bindings to their own module file which is likely a bit easier to grok for most, and a good place to put extra functionality (e.g. custom impls for the generated types).

The code from this pr is split out from #247 for easy reviewing

[tschneidereit]

LGTM, modulo nits.

For future reference, I found this very hard to review because almost all of the changes are stylistic in nature and unrelated to the PR's description. I appreciate that while working on a functional change it's very common to feel the need to apply refactorings like this, and don't want to dissuade you from following that. What I'd prefer is if you'd always split them out into separate commits, and mention that fact in the PR. As long as you ensure that those separate commits truly don't include any functional changes, that allows reviewers to skim them much more quickly, and apply more dedicated focus on the actually important changes.

[tschneidereit]

And now I see that a lot of these changes come from #248. That would have been really really good to know when reviewing this.

[vados-cosmonic]

Hey @tschneidereit yeah so this one is the most recent PR -- the stylistic changes are from the introduction of clippy in #248 -- I should have been more explicit about the PR order.

I see how you got to this PR first, the order in this comment is backwards

[vados-cosmonic]

Yeah my apologies there -- maybe what I can do here is just make the rest of them Drafts until the previous ones have landed. Stacked commits don't really work on forks, but leaving them in Draft and leaving a note should have been enough to give a better heads up.

[tschneidereit]

Leaving stacked PRs in draft certainly works, but just giving an explicit heads-up should also be enough. Just requiring reviewers to have a global view of all PRs when reviewing a single one isn't great.