Unify chainParams, signer, and observers lifecycle

[swift1337]

Currently we have lots of hardcoded places for each chain type:

type AppContext struct {
	chainsEnabled      []chains.Chain
	evmChainParams     map[int64]*observertypes.ChainParams
	bitcoinChainParams *observertypes.ChainParams
	solanaChainParams  *observertypes.ChainParams

        // ...
}

We should have a generic way of recording, registering, (de)provisioning chains, observers, and signers for zetaclient. Orchestrator should not be aware of concrete implementation.

[swift1337]

Followup from @ws4charlie #2497 (comment)

Just to track. The config file reloader would be a piece of future refactor to allow the observer signer to feed config (e.g. their own endpoint for the chain) of newly enabled chains.

I think if we want to support live config reloading, it would require significant effort because we want to make sure that every config part can be updated. Thus, we need to support all Zetaclient components (de)provisioning. It would be confusing if we support only a subset of fields.

I recall that we also wanted to clean up config naming. Probably it's a good time to revamp config props naming, supporting YAML and ad hoc config reloading.

[swift1337]

@ws4charlie #2497 (comment)

Are newly created or newly deleted observer and signer pair always exactly match?

AFAIK, theoretically we want to support different validator variations, e.g., observers but not signers, observer & signer, etc.

If, after operational experience, this is not the case, let's make this architectural decision and ensure that we always need to have a pair of observer/signer. This will indeed simplify the code.