Split the plugin to JCasC API and JCasC plugin

Currently JCasC exists as a single plugin. In longer term it may cause issues with adoption of the plugin:

* The plugin depends on the Jenkins core, and there are some fixes needed there to make the plugin more reliable (e.g. we need new milestone to prevent race conditions with Job loading)
* If we update the entire plugin to the new core, plugin developers would have to bump the core requirement as well if they want to support JCasC. In some cases it may be impossible (support policies, user requirements)

I would propose to split the plugin to two ones:

* "Jenkins Configuration-as-Code API" plugin. Targets Jenkins 2.60.x
* Extension points for Plugin developers
* "Jenkins Configuration-as-Code" plugin. Generally targets recent LTS versions of Jenkins
* Boot logic: Initializer, plugin management, etc.
* Configurator implementations for Jenkins Core
* Complex extension implementations, e.g. DataBoundConfigurator. It may stay in the API plugin, but eventually it may need to pick new core features like `@DataBound` proposed by @ndeloof

Such plugin split would support evolving the JCasC plugin along with the core, but at the same time it will allow more conservative plugin developers to integrate with the plugin.