WIP: Add openconnect_set_id_option to API, and --local-id to CLI

This addresses #133.

Examples:

• --prot=anyconnect --local-id platform_version="$(uname -a)" --local-id device_uniqueid=A1C043E19F166410ABC2C2BDC8C376DA4F7F03513FBE1DCB3A066F22C65C12B6 --local-id device_type="VMWare ESX whatever" (replicates behavior of openconnect_set_mobile_info API function)
• --prot=nc --csd-wrapper=trojans/tncc-emulate.py --local-id TNCC_DEVICE_ID=f00faaabbcccdd --local-id TNCC_FUNK=1 (pass arbitrary TNCC_* variables to trojans/tncc-emulate.py)
• --prot=gp --local-id os-version="Windows 10 x64 SP2 blah blah" --local-id app-version="5.3.3-1" --local-id host-id="deadbeef-dead-beef-dead-beefdeadbeef" (set os-version, app-version/gpclientversion, and host-id fields submitted to {login,getconfig}.esp to non-default values

Things that are great about this:

• No more worrying about how to design an API for random field X that some VPN wants.
• No more cluttering global struct openconnect_info with random field X that some VPN of a specific protocol wants
• Can easily specify repeated values of fields like AnyConnect client MAC address, with --local-id mac_address=aa-bb-cc-dd-ee-ff --local-id mac_address=11-22-33-44-55-66, and have the <mac-address-list> XML correctly constructed.

Things I don't love about this…

• We're stuck with the existing openconnect_set_mobile_info API function which manages to be not just redundant and overly-specific but also incomplete (because it doesn't include the originally-proposed mobile_mac_address parameter).
• Key names are randomly protocol-specific. For example, …

  • Cisco device_uniqueid, Juniper TNCC_DEVICE_ID, and GlobalProtect host-id are basically all the same thing.

  • Cisco platform_version and GlobalProtect os-version are basically the same thing too.

  • Does this matter? Should we try to "unify" these under generic names?

    We already have generic APIs and CLI options for platform (--os={win,linux,etc}) and client hostname (--local-hostname); despite the protocol-agnostic naming, these are used in ways that are entirely protocol-specific.

    Should we consider this past pattern a mistake? Should we reserve it for values that are reasonably transparent, like client hostname, but not opaque values like obfuscated device ID? If so, where do we draw the line?