Allow easy configuration of cloud-profiles

[jarhodes314]

Is your feature request related to a problem? Please describe.
Following #3174, it is possible to run multiple mappers using cloud profiles. However, in order to make the feature usable, we need a way to configure cloud profiles.

1. A way to migrate an existing tedge.toml cloud configuration to a cloud profile.
2. A way to configure multiple tedge-mapper services that use cloud profiles.

At the moment, it is only possible to configure a profiled value if none are set, to make it unambiguous whether a particular cloud is using profiles or not. This means migrating using the tedge cli would involve unsetting all the c8y configurations, and then setting each one with the named profile.

There are some other considerations to be made around configuring profiles too:

• Do we need device certificate and device key to be configurable per cloud instance? This would be necessary if people wish to connect a device to multiple subtenants of the same management tenant
• Do we want a feature in e.g. tedge reconnect to support reconnecting to all clouds (or profiles for a specific cloud), so we don't have to worry about what the different profiles are called?

Describe the solution you'd like
Add a subcommand to enable profiles for a particular cloud. e.g. tedge config profile enable c8y (that feels a bit lengthy to me, I haven't spent long thinking about that). This could then ask the user for what they wish the profile to be called (e.g. @cloud/@edge) and what MQTT topic prefix they need. The main thing this will do, other than setting any new configurations we ask about, is to change the Multi::Single in tedge_config_dto.c8y to be Multi::Multi with the named profile and persist those changes to tedge.toml.

For services, we could make use of systemd service templates, like we do for the socket activated service in the remote-access-plugin. This would make it relatively easy to configure different tedge-mapper service definitions, although that is systemd specific. We will also need a solution for non-systemd use cases.