subnet: allow --enable-dhcp=False/True syntax, again

Till neutronclient 2.3.4, we allowed the following syntax to enable or
disable DHCP: --enable-dhcp=False or --enable-dhcp=True. Since
I52d05ec2284b6910a33df4a5cb7dc3888737acb6 was merged, it's not the case
anymore.

Client libraries should be backwards compatible.

The change that introduced the regression cannot be reverted. First,
because it's correct in essence and fixed a valid bug in neutron client
CLI, and second (and more importantly), we don't want to break backwards
compatibility for users that currently use 2.3.5+ version that already
included the new style of the argument.

So we need to support both new and old styles for setting the attribute.

It's sad, but argparse module that we use to parse CLI arguments does
not allow to distinguish between '--enable-dhcp=smth' and '--enable-dhcp
smth' variants of the argument. This limitation means that an argument
with nargs=argparse.OPTIONAL that would be useful to cover both styles
with single entry would consume the next argument from the command line
if it's present and does not seem to be another option argument defined
for the parser. Meaning, it would break some cases, f.e. when
--enable-dhcp is passed right before subnet name. In that specific case,
the argument would consume the name as the value of the argument and
break the client.

That's why for this specific fix, we're forced to use
--enable-dhcp=False and --enable-dhcp=True as argument *names*. It's
ugly as hell, so let's hide that mess from users by suppressing help
entries for new arguments.

PS: And Oh Lord the Mighty, thank you for only two possible values for
boolean attributes!)

Closes-Bug: #1401555
Change-Id: Ib374d1cc499e4f1e5242f1b438bc65512c109e40
Merge "subnet: allow --enable-dhcp=False/True syntax, again"