Issue Description: 

We do not currently have the ability to add/edit/remove shards from the configuration of a Fleet Manager without writing database migrations.

Having the ability to provide Shards via external configuration or via API will allow us to more easily manage the configuration on a per-environment basis and also allow us update the configuration of a Shard without having to perform a release of the code/write a database migration. If we need to rebuild or replace a data plane this is particularly painful for us.

This epic is for us to introduce a first implementation of our Shard management. 

Acceptance Criteria: 

• We have the ability to add/remove/update the current configuration of Shards via external configuration or an API
  • We need to investigate the basic configuration required at this time. From our current setup this looks like it could include
    • id - Do we need the ocm id of the cluster so that we can do automated installation into the shard in the future e.g. install our own AddOn
    • shard id (this maps to the rhd-user-id claim in the JWT token the shard uses to authenticate)
    • canonical_router_url
    • ...
• We have the ability to mark a shard as either enabled or disabled so that it can be added to the Fleet Manager, but not considered for scheduling workloads.
• We can easily extend the configuration of shards in the future with additional metadata that can be interpreted by new features in the Fleet Manager

Additional Information: 

• Consider following the approach taken by RHOSAK where the list of Shards available is injected on per-environment basis through configuration
  • https://gitlab.cee.redhat.com/service/app-interface/-/blob/master/data/services/managed-services/cicd/saas/saas-kas-fleet-manager.yaml#L587-619