need to improve shared modules on `bitcoin_core_sv2`

[plebhash]

#574 and its PR #602 allowed us to introduce shared modules into bitcoin_core_sv2, which reduces code duplication

however, as I work on #268 and #441 I'm noticing that there's still things to improve here

ultimately we should have a crate module structure that's easy and intuitive to navigate and maintain, but we're not there yet

[plebhash]

to be fully honest, my work on #268 and #441 (where we need shared modules for v30x+v31x+v32x) is making me question the current direction

there's still code duplication, mainly due to the way the modules were originally structured

moreover, we're being forced to use #[path = "..."] syntax, which is getting a bit confusing to navigate

so things are not scaling well, and I'm worried about long-term maintainability

[bit-aloo]

to be fully honest, my work on #268 and #441 (where we need shared modules for v30x+v31x+v32x) is making me question the current direction

there's still code duplication, mainly due to the way the modules were originally structured

moreover, we're being forced to use #[path = "..."] syntax, which is getting a bit confusing to navigate

so things are not scaling well, and I'm worried about long-term maintainability

Personally, I think I would be okay with bringing back some of the duplication for now. As long as each version's implementation stays simple, explicit, and easy to follow, I think that's a reasonable tradeoff. At this stage, I would probably prefer a bit of visible duplication over an abstraction that may still change as we learn more.

I am also a little hesitant about introducing shared modules that combine multiple versions (for example, v30x + v31x + v32x). My feeling is that it might be simpler to keep each version self-contained for now, even if that means some modules end up looking quite similar. We can always refactor that duplication later once we have a better understanding of what is actually common across versions.

If I remember correctly, this was also the motivation behind the current direction, that keeping the versioned modules separate would be more future-proof, even if it introduced some duplication. I still think that makes sense.

We also don't have the full picture yet. v32 will likely introduce new handlers with more significant differences from the previous iterations. The new IPC methods are still somewhat of a blind spot (they add new stuffs every iteration), and even the Unix backend may continue to evolve/change. Because of that, I am not sure we have enough information yet to settle on the right shared abstraction.

Maybe it would be worth keeping the v3xx modules as simple and explicit as possible for now, even if that means bringing back some duplicated code. Once v32 is in place and we have a better understanding of what is genuinely shared across versions, we can revisit the structure and factor out the common pieces. My intuition is that we will arrive at a cleaner abstraction if it's informed by the implementation, rather than trying to define it upfront.