[avalanche] Add compile and runtime assertions that cs_main is not held for some avalanche Processor functions

Summary:
Since PeerManager takes a lock on cs_main in order to verify proofs, there is a potential deadlock if cs_main
is taken (commonly done in validation code) and then cs_peerManager is taken (commonly done via Processor).

PeerManager takes a lock on cs_main in order to verify proofs, making the typical lock order:
cs_peerManager (processor.cpp) -> cs_main. As avalanche post consensus develops, its easy to accidentally
introduce an inverted lock order by accessing the avalanche API in validation code:
cs_main (validation.cpp) -> cs_peerManager (processor.cpp).

This patch introduces additional low-hanging-fruit compile and runtime assertions to help catch these as quickly as possible.

Test Plan:

ninja check check-functional

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Subscribers: Fabien

Differential Revision: https://reviews.bitcoinabc.org/D12373