Landing the controller-rename feature branch for 1.26

[Tim Penhey]

Firstly, the branch name isn't entirely what it is now :-)

It was initially just a branch to catch the work where we renamed system
-> controller for master. But it then grew to include the removal of the
'jes' feature flag.

This brought in a number of changes, particularly the cache.yaml file
for the locally cached connection info, and logging to mongo by default.
This also caused a number of CI failures, which was mostly expected,
hence the change happening in a feature branch.

Part of the preparation for the Juju Controller work becoming mainstream
and fully supported was a re-jig of the CLI around multiple
environments, and this grew several breaking changes with respect to
bootstrap, switch, and destroy-environment.

Here is my proposal to get the work landed into 1.26.

1) Firstly, change the destroy-environment command to better deal with
controllers.  The current destroy-environment command was reworked into
three difference commands.  We move the new destroy-environment to the
top level replacing the older one, and add fall-backs that effectively
run either destroy-controller or kill-controller.

2) Add a new feature flag "juju-2.0". With this feature flag enabled,
the destroy-environment command will error if given a controller
environment to destroy.  We also use the feature flag to control
behaviour of bootstrap.  Without the flag, we do what we currently do.
With the flag we create the additional workload environment.

I'd like to land the controller work without the juju-2.0 flag first,
and have a separate feature branch that deals with the 2.0 behaviour.

Also, the big change with taking off the 'jes' feature flag and adding a
'juju-2.0' flag is that the 'juju-2.0' flag only impacts the CLI. All
the features and API endpoints exist.

Thoughts?

Tim