Use non-zero costmodels in Imp tests

[teodanciu]

Description

At the moment, Imp tests are using zeroCostModels with Plutus scripts, which, in essence means that the way we are setting the budget in the redeemers has no impact on script execution.

In this PR, I have switched to using the cost models provided by Plutus for testing.
Making the switch revealed that we weren't computing the budget correctly, but because of the zero cost models, the problem hasn't manifested.
Specifically, the budget (set in the redeemers) depends on the value of the fee, which in turn depends on the value of the redeemers (I think via the size of the transaction).

In master, the order of the fixup is: fixupRedeemers >=> fixupFees ... With non-zero cost models, tests are failing because of unsufficient budget (that doesn't take the fee into account).
In this PR, I'm first computing the fee, maximizing it with respect to the budget (so assuming the maximum budget), then computing the real budget, with a previously computed more realistic fee.
I also added 10% to the fee as a margin, because in some cases it would still go over.

Any suggestions for a more elegant solution are welcome!

Closes #4404

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated
• All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages.
  New section is never added with the code changes. (See RELEASING.md)
• When applicable, versions are updated in .cabal and CHANGELOG.md files according to the
  versioning process.
• The version bounds in .cabal files for all affected packages are updated.
  If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
• Code is formatted with fourmolu (use scripts/fourmolize.sh)
• Cabal files are formatted (use scripts/cabal-format.sh)
• hie.yaml has been updated (use scripts/gen-hie.sh)
• Self-reviewed the diff

[lehins]

Any suggestions for a more elegant solution are welcome!

I think we could find a fix point by calling fixup functionality until transaction stops changing. This would require some thought about making most fixup functionality to be idempotent.

That being said, we could merge this PR as-is and figure it out in the future. I leave this choice up to you @teodanciu If you decide to postpone this work until later then just make sure you create a ticket about improving fixup functionality

[teodanciu]

Merging because I think it does bring value to use realistic costmodels, but agree it should be better! Added an issue for this: #4784