Improve resilience of future PParams

[lehins]

Description

This PR adds a test for futurePParams prediction and fixes a problem where it would not work correctly when there was no TICKs before the point of no return (first 4k/f slots)

This isn't really a problem in practice, because of this property that Sam pointed out:

if there isn't a single block in 3k/f slots, the ledger state goes out of view and no further blocks can be made

But it is nice to fix it regardless, because it simplifies the futurePParams state transition a bit

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated
• 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)
• 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)
• 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

[teodanciu]

I suppose we don't have this hypothetical problem for Shelley, because there PotentialPParamsUpdate gets directly computed based on the votes rather than on the predicted-solidifed values, right?

[teodanciu]

If you want to keep the documentation up to date, you could add this to the paragraph explaining the changes at the epoch boundary:
We also predict the parameters after resetting the pulser, in order to cover - for completion - the case in which there is noTICKbefore the first4k/f slots.

[teodanciu]

Looks good to me, just some questions for my own understanding.