Changes required for Configuration As Code (and plugin install)

[arranubels]

These are the changes that are required for the method of installing Configuration as Code and Plugins.

This is in conjunction with: base2Services/ciinabox-ecs#136

A couple notes;

• The groovy scripts used to setup jenkins have been removed, as they should be automatic with Configuration as code
• Configuration as code basically resets the config you have specified each reboot
• It untars an "overlay.tar" which ciinabox-ecs generates, it contains the plugin information, any groovy scripts, etc. It's untarred into the container at launch from ENV $SRCTAR, which supports a couple extensions.
• Plugins-local is created, which is a modified version of what comes with the jenkins repo, it allows for plugins to be installed from a local source.
• Created a folder /inits/ which is a mimic of Mysql's docker version of the same thing. Current it executes /inits/*.sh (as jenkins user) every time the container starts. This is to mimic the type of behaviour that Configuration As Code currently implements, of resetting the setting each startup. Ideally, this means that you will get to a system of deployment using ciinabox-ecs: generate deploy update-jenkins, which simply restarts or rebuilds the docker container, which should be faster.
• Configuration as code seems to be moving towards a: deploy configure export restart sort of setup, see screenshot:
  
• There is an example repo that I have created to use this. CAC hasn't yet been made the default repo, even in the ciinabox example code I have submitted. (As of writing.) https://github.com/base2Services/ciinabox-cac-example .
  
• I might have pushed some HPI etc into this repo, as a result of some testing and before configuration as code became an official plugin: https://wiki.jenkins.io/display/JENKINS/Configuration+as+Code+Plugin That will need to be squashed before accepting the PR.
• Configuration as code currently doesn't disable the setup wizard. As a result I've had to add it to java_opts. For this to work it requires changes to jenkins-parent (official repo) on behalf of Configuration as code. But once that has been changed it can be removed.
• Example repo doesn't setup a user using configuration as code, so you get a wizard. A fully configured you won't get that
  
• S3 access for s3get.py depends on the default EC IAM role, ciinabox-ecs handles this properly
• Configuration as code's export functionality is highly unstable, you have to sort of disable plugins until it works, so it's actually a lot of guess work atm. The only real way of figuring out what to configure / how to configure, is by using a reference, such as the source code or examples. Despite a 1.0 release it's VERY early
• This can be used to deploy plugins without using Configuration as code. The plugin component should be stable. Just need to verify that install-plugin-local.sh works with each new jenkins version. (Monitor install-plugin.sh for changes.) Configuration as code however requires the new plugin install system at the moment. (It can be installed the previous way, but it has to do with Cloudstats and Cloudwatcher also needing to the installed. Plus the old way is depreciated.)