work around 'docker rm -f' weirdness
I've been seeing

~# docker rm -f weave
Error response from daemon: Cannot destroy container weave: Driver devicemapper failed to remove root filesystem 29e46c3e400ee3c8654f2b06a0f6d97bde98dfeb9bb61d25195dba38c04324fc: Device is Busy

whereas the corresponding two-step 'docker kill' + 'docker rm' works
fine.
create bridge in 'weave expose/hide'
since they really need the bridge
refactor: extract command checking helper
disable offloading on weave bridge
since w/o it the kernel just ignores the PMTU when the host talks to
weave via 'weave expose'

Fixes #52
remove detritus
we haven't depended on pipework for a while
refactor: extract container network configuration
and use more function parameters in preference to global vars
ignore conntrack result in 'weave stop'
so we exit with status 0, since not having any existing flows is
perfectly normal
leave networking alone on 'weave launch' unless we start container
remove masquerading rules on 'weave stop/launch'
Leaving iptable masquerading rules behind is a bad idea when weave is
re-launched with different ip subnet settings. So now we remove the
rules on 'weave stop' and also on 'weave launch' (in case weave had
been stopped in ways other than 'weave stop').

To make the rule removal easier, we create the rules in a user-defined
WEAVE chain.

Note that this will break old weave installations, since the rules
created by those are left behind. Easiest upgrade path is to restart
the machine. Or, for the brave, run `iptables -t nat -S POSTROUTING | grep weave | sed 's/^\-A/-D/g' | while read line; do iptables -t nat $line; done`.

Fixes #48
remove WEAVE iptable chain on 'weave stop'
No point keeping it around.

Also, simplify idempotence of masquerading setup.

Follow-up to issue #48.
add 'weave reset'
Closes #20.
Merge remote-tracking branch 'upstream/master'