No support for invalid-before and invalid-here-after in eras up to Alonzo

[newhoggy]

Changelog

- description: |
    * No support for invalid-before and invalid-here-after in eras up to `Alonzo`
    * No support for tx-aux-scripts in eras up to `Alonzo`
    * `invalidBeforeTxBodyL` now takes `BabbageEraOnwards` instead of `AllegraEraOnwards`.
    * `TxValidityLowerBound` constructor takes `BabbageEraOnwards` instead of `AllegraEraOnwards`.
    * `TxAuxScripts` constructor takes  `BabbageEraOnwards` instead of `AllegraEraOnwards`.
    * Delete `ShelleyEraOnly` and `AllegeraEraOnwards` and associated functions.
    * Modify `TxValidityUpperBound` constructor to take `BabbageEraOnwards` instead of `ShelleyBasedEra` and remove the `Maybe`.
    * Introduce `TxValidityNoUpperBound` constructor 
    
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
  - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
  # - improvement    # QoL changes e.g. refactoring
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...

Context

Removing support for features in era up to Alonzo simplifies the code a lot.

How to trust this PR

Highlight important bits of the PR that will make the review faster. If there are commands the reviewer can run to observe the new behavior, describe them.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. See Running tests for more details
• Self-reviewed the diff

[Jimbo4350]

This is the direction we are going in however I want to see how my new abstraction works in the cli first. After I make a small PR there we can revisit this PR and make a sweeping change, rather than breaking the api now and then potentially again in the near future.

[Jimbo4350]

With the above in mind I want to see if its possible to not break the existing api at all for the time being and introduce the new api alongside the existing api. The wallet team will (rightly) be very annoyed if we make them go through two breaking changes one afeter the other. I need to explore the smoothest transition possible and we can use the cli as a first trial.

[github-actions]

This PR is stale because it has been open 45 days with no activity.

[github-actions]

This PR is stale because it has been open 45 days with no activity.

[github-actions]

This issue was closed because it has been stalled for 60 days with no activity.