scripted-diff: rename CChainState -> Chainstate

-BEGIN VERIFY SCRIPT-
sed -i 's/CChainState/Chainstate/g' $(git grep -l CChainState ':(exclude)doc/release-notes*')
-END VERIFY SCRIPT-

Co-authored-by: MacroFake <falke.marco@gmail.com>

doc/design/assumeutxo.md

@@ -41,7 +41,7 @@ be of use.
 
 Chainstate within the system goes through a number of phases when UTXO snapshots are
 used, as managed by `ChainstateManager`. At various points there can be multiple
-`CChainState` objects in existence to facilitate both maintaining the network tip and
+`Chainstate` objects in existence to facilitate both maintaining the network tip and
 performing historical validation of the assumed-valid chain.
 
 It is worth noting that though there are multiple separate chainstates, those
@@ -53,7 +53,7 @@ data.
 
 ### "Normal" operation via initial block download
 
-`ChainstateManager` manages a single CChainState object, for which
+`ChainstateManager` manages a single Chainstate object, for which
 `m_snapshot_blockhash` is null. This chainstate is (maybe obviously)
 considered active. This is the "traditional" mode of operation for bitcoind.
 

doc/developer-notes.md

@@ -962,7 +962,7 @@ void CTxMemPool::UpdateTransactionsFromBlock(...)
 
 ```C++
 // validation.h
-class CChainState
+class Chainstate
 {
 protected:
     ...
@@ -983,7 +983,7 @@ public:
 }
 
 // validation.cpp
-bool CChainState::PreciousBlock(BlockValidationState& state, CBlockIndex* pindex)
+bool Chainstate::PreciousBlock(BlockValidationState& state, CBlockIndex* pindex)
 {
     AssertLockNotHeld(m_chainstate_mutex);
     AssertLockNotHeld(::cs_main);