Remove the `deriving-aeson` dependency

[Unisay]

#7820 raised the aeson lower bound to 2.3 and had to add allow-newer exceptions for deriving-aeson and microstache, whose Hackage metadata still caps aeson < 2.3. These exceptions only help builds inside this repository; downstream consumers building against CHaP have to rediscover them on their own, which came up as release friction in the #7820 discussion (#7820 (comment)).

deriving-aeson is a direct dependency of plutus-core, used only to derive the cost model JSON instances via CustomJSON. Plain aeson generics (genericToJSON/genericToEncoding/genericParseJSON with explicit Options) can express the same instances, so both the dependency and its allow-newer exception can go. The serialized JSON format has to stay byte-identical; it is pinned by the compile-time TH loading of the cost model data files, the cost model interface tests, and the ledger API param name goldens. The only public API change is that PlutusCore.Evaluation.Machine.ExBudget stops exporting the LowerInitialCharacter helper type, which exists solely to support deriving-aeson.

The microstache:aeson exception cannot be removed the same way: microstache enters the build plan only through criterion (benchmark components), and even the latest criterion release requires it. That exception stays until haskellari/microstache#47 is resolved upstream.

Acceptance criteria:

• plutus-core no longer depends on deriving-aeson, and allow-newer: deriving-aeson:aeson is removed from cabal.project.
• The JSON encoding of the cost model types is unchanged: existing TH loading, tests, and goldens pass without modification.
• Appropriate changelog entry exists.