Fixed LXC/KVM bridge settings for maas and other environments

This PR aims to address a number of bugs all related to LXC or
KVM containers on MAAS nodes not getting IP addresses, got stuck
in "pending" or failed to start due to networking issues:
 * http://pad.lv/1368976
 * http://pad.lv/1271144
 * http://pad.lv/1386189
 * http://pad.lv/1340261
 * http://pad.lv/1386575
 * http://pad.lv/1345433

Most of the issues arise from the way Juju creates a "br0" bridge
device and attaches the "eth0" interface on the machine to it, so
containers can use DHCP to acquire an IP address from MAAS. However,
after lots of testing the following fixes and changes were done:
 * Removed the "network-bridge" MAAS environment setting (introduced
   in #227). This setting has a misleading name (it's supposed to
   allow users to pick which network interface on the machine to
   attach to the bridge, not the name of the bridge itself) and
   cannot work as intended (machines have different network interfaces
   in general). The impact of this change should be minimal, as it
   was never used properly.
 * A few changes made to common.Bootstrap and cloudinit.FinishMachineConfig.
   BootstrapParams struct now has a "ContainersBridgeName" field. When
   set, it will cause the LXC_BRIDGE setting in the agent config on the
   bootstrap node to have the given value. Because the LXC_BRIDGE setting
   is used to determine the network bridge name for starting both LXC and
   KVM containers, setting ContainersBridgeName at bootstrap time (as the
   MAAS provider does now) will override the silent defaults otherwise
   used ("lxcbr0" for LXC and "virbr0" for KVM containers).
 * MAAS provider changes simplified the generated cloudinit scripts (e.g.
   do not try to "restore" network interfaces file before adding the
   bridge config), a single "juju-br0" bridge is created and set to get
   an address using DHCP from the machine's primary network interface.
 * Added code to discover the primary NIC from the lshw data MAAS holds.
   This should work in most cases, including with more complex networking
   setup per node (e.g. using custom preseed or commissioning scripts).
 * I discovered the networker worker is not starting for machines deployed
   after bootstrap due to a missing JobManageNetworking (see DeployService
   and AddUnits), but that's fine because it was interfering with the bridge
   network config generated at cloudinit time.
   So, as a temporary measure, no JobManangeNetworking will be added to the
   bootstrap nodes by default and the networker will only work in "safe mode".

I spend the last 3 days extensively testing the changes with live environments
on MAAS, EC2, and local, to ensure no regressions are introduced and both
LXC and KVM containers get proper addresses on MAAS.