nuke validation

[ismaelsadeeq]

validation.cpp isn't a misnomer; it's a validation file that includes block validation, mempool validation, chainstate management, consensus helpers, and friends well over 5,000 lines across multiple concerns.

This makes it hard to navigate, and hard to reason about.

This PR breaks it apart by moving code to where it actually belongs.

• Mempool acceptance logic moves to mempool_validation.{h,cpp}
• Block validation to block_validation.{h,cpp}
• CScriptCheck to script/script_check.{h,cpp}
• Transaction consensus helpers to consensus/tx_verify.{h, cpp}
• Coins helpers to coins.{h, cpp}.
• Block import to node/blockimport.{h, cpp}

Once the extraction is complete, what remains in validation.{cpp,h} is exclusively Chainstate and ChainstateManager, so the files are renamed to chainstate.{h,cpp} to reflect what they actually contain. node/chainstate.{cpp,h} is renamed to node/chainstate_load.{cpp,h} beforehand, also for clarity.

The circular dependencies here actually makes the underlying tight coupling more obvious.

• block_validation -> chainstate -> block_validation — because block_validation.cpp functions take Chainstate& and ChainstateManager& parameters, pulling in
  chainstate.h, while chainstate.h needs types declared in block_validation.h.
• chainstate -> mempool_validation -> chainstate — for the same reason on the mempool side.

The circular dependencies are added to the lint allowlist as temporary known exceptions.

The path to resolving these is to reduce what the extracted functions need to take as parameters. Rather than passing a full ChainstateManager&, functions in block_validation and mempool_validation can be refactored to take narrower dependencies, for example, passing a BlockManager& directly, or introducing a small context struct which will be defined in a separate file, so they no longer need to include chainstate.h at all.
That work is left as a follow-up to keep this PR a pure move.

Pros of the end goal of this are:

• Faster incremental builds e.g a change to mempool logic no longer forces recompilation of everything that only cares about block validation
• Separation of Concern and Easier navigation, the filename tells you where to look, and that file aims to do just that, hence a clearer dependency graph — #include <block_validation.h> communicates intent; #include <validation.h> communicated nothing
• Aiming for better kernel boundary

On this branch, there are cons because this is an intermediate state.

• The circular dependencies (block_validation -> chainstate -> block_validation, chainstate -> mempool_validation -> chainstate) mean the physical
  separation is done but the logical separation is not the full benefit requires significant follow-up work
• Large include churn across the codebase makes the PR mechanically large and harder to review I think