Change `OneEraTxId` to wrap a `SL.TxId`

This is a refinement of #1028 motivated also by #2003

In the Consensus layer, we use `ShortByteString` as the underlying type for TxIds. However Ledger provides a more efficient hash representation as 4 `Word64` put together as `Hash HASH EraIndependentTxBody`.

Shelley already uses `SL.TxId` which is a newtype for `Hash HASH EraIndependentTxBody`.

```haskell
newtype TxId = TxId {unTxId :: SafeHash EraIndependentTxBody}
newtype SafeHash i = SafeHash (Hash.Hash HASH i)
```

Byron uses its own sum type for TxId:

```haskell
data instance TxId (GenTx ByronBlock)
= ByronTxId !Utxo.TxId
| ByronDlgId !Delegation.CertificateId
| ByronUpdateProposalId !Update.UpId
| ByronUpdateVoteId !Update.VoteId

type TxId = Hash Tx
type CertificateId = Hash Certificate
type UpId = Hash Proposal
type VoteId = Hash Vote

type Hash = AbstractHash Blake2b_256

newtype AbstractHash algo a = AbstractHash SBS.ShortByteString
```

We can use this conversion to create a new-style `Hash`:
```haskell
hashFromBytesShort ::
forall h a.
HashAlgorithm h =>
-- | It must be a buffer of exact length, as given by 'hashSize'.
ShortByteString ->
Maybe (Hash h a)
```
Which is guaranteed to not fail in this case. We need to combine it with:
```haskell
unsafeMakeSafeHash :: Hash.Hash HASH i -> SafeHash i
```

Depending on how we use these hashes, we should be able to do
```haskell
type instance GenTxId (HardForkBlock xs) = SL.TxId
```
therefore eliminating the performance issue in #2003.

From the top of my head, I know we use standalone TxIds for TxSubmission2 and TxMonitor, so we should first check if that creates a problem for this conversion. We might need to keep backwards compat for some versions.

In all other cases, I think the TxId is derived from the Tx, so we know in which summand of `GenTx ByronBlock` we are.