Recursion: Raw transaction endpoint for inscriptions

[alpergundogdu]

We've talked about this endpoint a few months ago with @raphjaph on "Best in Slot <> ord" telegram channel and he mentioned there are other teams looking for a recursive raw transaction endpoint and invited us to open a PR for it.

In our use-case, we want to be able to track the inscriptions' old pkscripts and change the artwork based on some calculations over them. We can get the current txid via /r/inscription/<INSCRIPTION_ID>, we can get the genesis txid via inscription_id so we can apply sat movement rules to current sat location and track the inscription back to the genesis txid.

In order to do that, we need vout (pkscript and value), vin (txid and vout), and also blockhash to get the blocktime of the target transaction (we can use /r/blockinfo/<QUERY> to get the blocktime from blockhash).

I'll attach a PR to this issue in a bit, we updated the code per casey@'s initial suggestion on PR 4100.

Adding just the txhex and parsing client side could be error-prone if a new transaction version is introduced, the parser may stop working and the inscription may lose all history after a single new version tx.

For now, we chose a limited, stable set needed for base ordinals sat tracking, so we can assume these will always be in bitcoin as long as inscriptions work.

Verbose endpoint can keep some optional future fields in case another team needs more information about a tx and this information is also part of bitcoin and/or ordinals rules so it will always be available, new fields can always be added to the response but as casey@ mentioned we can never remove a field after it is introduced so we tried to limit the response fields as much as possible.

[alpergundogdu]

Opened PR 4109 for this.