Cardano Updates

SUBDELEG rule implementation

Introduced instances for the simplest of the blocks.

This commit defines a new library where the main definitions persist.
In the library there will be definitions for the era angostic types.

As blocks/v0 is common for all eras, it doesn't cripple into the
era libraries.

Introduced instances for the simplest of the blocks.

This commit defines a new library where the main definitions persist.
In the library there will be definitions for the era angostic types.

As blocks/v0 is common for all eras, it doesn't cripple into the
era libraries.

Introduced instances for the simplest of the blocks.

This commit defines a new library where the main definitions persist.
In the library there will be definitions for the era angostic types.

As blocks/v0 is common for all eras, it doesn't cripple into the
era libraries.

* Remove re-exports of `Reward` and `RewardType`
* Add re-exports for `Addr`, `AccountAddress` and `AccountId`

This module only tested that sizeTxF equals serialized transaction.
Those tests are useless since we are switching the acrtual implementaion
of the function to be exactly that.
There was also one unit test that checks fee estimation, wehere we
have a much more powerful property test like that, which runs for all
eras.

* Fix rendering of ascii-art in the haddock as code
* Fix spacing and arrows in ascii-art for address headers
* Export `AddressBuffer` definition for the sake of haddock (doesn't
  make it useable outside the module)

Improve snapshot creation performance

There was some duplicate computation as well as redundant retention of
unnecessary data in the `SnapShots`. This commit introdcues a better
approach that eliminates the need for the above overhead, while
temporarely keeping the old appraoch with some assertions that will be
further used to confirm accuracy on mainnet data. Keeping old approach
should not incur any overhead, since it was made lazy and is only forced
during testing with assertions. The plan is to remove this old approach
before the next release, however there is no danger to go to production
with these follow up changes, due to lazy evaluation of an old approach.

See my comments on #5516 for more details on individual optimizations.

Because it conflcicts with our internal type.