We should not have a CASESessionManager per DeviceController

[bzbarsky-apple]

Problem

CASESessionManager was changed to be fabric-independent, but we still have one per DeviceController (so one per fabric in the setup where we have DeviceControllers).

This causes a few problems:

1. We can't easily implement the suggestion in Don't try to do something with message delivery failures on other fabrics. #16157 (comment) because we'd need to register all the CASESessionManagers as listeners for failed message delivery and because they are fabric-independent they would all try to restart sessions, unless we add some sort of filtering by session.
2. We can't easily fix the broken interactions between CASEClient and CASESessionManager described in Establishing a CASE session tears down existing sessions for the peer #15986 because there are multiple CASESessionManagers floating around and we would need some way to find all of them.

Proposed Solution

Move the CASESessionManager into CHIPDeviceControllerSystemState and have DeviceController just point to it, not own it.

[bzbarsky-apple]

Some specific issues regarding current members of DeviceController that are in the way of doing this:

1. mCASEClientPool would need to move into CHIPDeviceControllerSystemState (or into CASESessionManager?)
2. We'd need to sort out what happens with mIDAllocator. See also Multiple instances of session ID allocator create session ID collisions at shared Matter port #12821
3. We'd need to sort out mDNSCache. Maybe that's getting removed, though.
4. Would need to sort out what happens for mDevicePool.

@jtung-apple @msandstedt @mrjerryjohns

[bzbarsky-apple]

Maybe the answer for now is that mIDAllocator, mCASEClientPool, mDevicePool all move into the system state?