Improve multi-party status information (if enabled) to aid registration automation

[peterbroadhurst]

Currently we have some information about multi-party status, bundled into the /status API on a namespace.

This is deliberately lightweight in-memory information from the multi-party manager (if it's enabled) - so it includes very basic things like if registration is completed with a boolean, but if it's not completed it doesn't go away and do any heavy lifting.

However, for users with multi-party turned on the information is insufficient to track registration, or diagnose issues with registration.

This issue requests additional information in a dedicated /status/multiparty endpoint:

• Ensure the status of catchup etc. for blockchain listeners built on FFTM propagates through to FF listener status
  • First step is an investigation to determine if this is available, as it was the architectural intention it would be for FFTM based plugins. But I suspect we've got a couple of missing pieces between the FFTM and EVMConnect codebase that means not all the information is propagating
• Add the new status endpoint to how a proper structure for the multi-party status - ensuring at minimum:
  • Is multi-party enabled
  • If a node registration is pending, what is the message ID
  • If an org registration is pending, what is the message ID
  • The list of smart contracts configured
  • Which one the listener is active against, and and ID of the listener
  • The status of the listener, which should be the same output as if you went directly to the listener