[10.0] Locking configuration once it becomes active

The configuration process should be:

1. Start with a fresh inactive configuration
2. Fill all the configuration fields (at least the important ones, the current validation could be fine). The configuration will remain inactive
3. Explictly make the configuration active
4. Lock the configuration once it becomes active to prevent further changes.

If the user wants to change anything that is locked, he can create a new configuration and delete the old one. This should make the user notice about important changes in the configuration that will likely affect the system
Note that some of the field might remain editable as long as the overall system doesn't get affected by the change (search attributes could be editable, for example).

In addition, copying a valid active configuration is possible, but the new configuration will be disabled by default, and will need explicit activation.

The goal is to make visible to the user the fact that he's creating a new configuration, not editing an existing one. If you make a change in the uuid internal attribute of a valid configuration, that's not a change limited to a simple field edition; the "old" configuration isn't valid any longer.

In addition, once the configuration is active we should be able to run the user:sync process

Related to
https://github.com/owncloud/user_ldap/issues/27 (save button in wizard)
https://github.com/owncloud/user_ldap/issues/82 (submit button + user:sync)
https://github.com/owncloud/user_ldap/pull/10 (automatic activation of LDAP configuration)

@PVince81 @butonic

Start by reading related issues #27 and #82 and pull request #10, then locate the configuration activation flow and the user:sync entry point. Done means the intended inactive, explicit-activation, locking, copying, and synchronization behavior is specified and covered consistently.