Config Backend migration tool

name: Control block/configuration migration tool
about: Similar to #1078, this is a request for tools to assist Kea users who decide to change their back-end provisioning - in this instance, their configuration.  This should (ideally) cater for all scenarios, so not just changing which DB backend is being used, but also migration from not-CB to CB and vice versa

I don't think anyone else has opened this yet - but if we do tackle this, it would be worth bearing in mind that configuration/CB backend version control or logging might also turn out to be A Thing - so we need to consider that use case/evolution in the design too.

**Is your feature request related to a problem? ** See Support ticket #17332 for details of which customer for whom this would be useful.

The likelihood is that they will wish to implement CB backend on the DB backend on which it's available now, but migrate to their preferred DB backend, once there is CB support there too (as well as complete coverage of all configuration options in the CB - at the moment there isn't).

Update: As discussed in Porto, we'd like to make more generic. While the ultimate solution will likely cover Stork overseeing the migration, some parts of the functionality should be implemented in Kea. In particular, the following was discussed:

• config-get/config-set like commands that would retrieve/set the full configuration from CB

Once the above is implemented, it will open up plenty of opportunities for Stork. In particular, scenarios such as: "add subnets defined in a config file to CB, delete subents from config file, write updated config file to disk". The same can be repeated for other configuration elements (shared networks, classes, HR, etc).