Cardano Updates

The recent changes to `IsData` introduced a much faster alternative to
`fromBuiltinData`, namely `unsafeFromBuiltinData`. It's also *much*
smaller. Or rather, `fromBuiltinData` is really very big!

However, both of these are typeclass methods of `IsData`, and so even if
we onyl use one of them, GHC can't prune away the others. It still
constructs the typeclass dictionary with all three. This doesn't cost us
much runtime but *does* cost us lots of space usage.

The simplest solution I could think of was just to split up `IsData`
into a class per function. This allows us to only use the constraints
that we really need, which cuts down on size a lot. In particular,
`wrapValidator` and friends only require an `UnsafeFromData` constraint.

There are still some places where we incur the other constraints, but
they're mostly off-chain. Main offenders are:
- `Oracle`: uses `fromBuiltinData` and returns a specific error if it
fails. It *might* be okay to use `unsafeFromBuiltinData` here, I'm not
sure.
- `StateMachine`: uses `toBuiltinData` to compare the expected state to
the new state. I'm not sure we can get away from this, unfortunately.

The recent changes to `IsData` introduced a much faster alternative to
`fromBuiltinData`, namely `unsafeFromBuiltinData`. It's also *much*
smaller. Or rather, `fromBuiltinData` is really very big!

However, both of these are typeclass methods of `IsData`, and so even if
we onyl use one of them, GHC can't prune away the others. It still
constructs the typeclass dictionary with all three. This doesn't cost us
much runtime but *does* cost us lots of space usage.

The simplest solution I could think of was just to split up `IsData`
into a class per function. This allows us to only use the constraints
that we really need, which cuts down on size a lot. In particular,
`wrapValidator` and friends only require an `UnsafeFromData` constraint.

There are still some places where we incur the other constraints, but
they're mostly off-chain. Main offenders are:
- `Oracle`: uses `fromBuiltinData` and returns a specific error if it
fails. It *might* be okay to use `unsafeFromBuiltinData` here, I'm not
sure.
- `StateMachine`: uses `toBuiltinData` to compare the expected state to
the new state. I'm not sure we can get away from this, unfortunately.

The recent changes to `IsData` introduced a much faster alternative to
`fromBuiltinData`, namely `unsafeFromBuiltinData`. It's also *much*
smaller. Or rather, `fromBuiltinData` is really very big!

However, both of these are typeclass methods of `IsData`, and so even if
we onyl use one of them, GHC can't prune away the others. It still
constructs the typeclass dictionary with all three. This doesn't cost us
much runtime but *does* cost us lots of space usage.

The simplest solution I could think of was just to split up `IsData`
into a class per function. This allows us to only use the constraints
that we really need, which cuts down on size a lot. In particular,
`wrapValidator` and friends only require an `UnsafeFromData` constraint.

There are still some places where we incur the other constraints, but
they're mostly off-chain. Main offenders are:
- `Oracle`: uses `fromBuiltinData` and returns a specific error if it
fails. It *might* be okay to use `unsafeFromBuiltinData` here, I'm not
sure.
- `StateMachine`: uses `toBuiltinData` to compare the expected state to
the new state. I'm not sure we can get away from this, unfortunately.

Add support for resuming chain sync.