Save GlobalProtect version reported by portal and parrot it back as client version

It appears that the GlobalProtect client and server software are versioned together, so that if the portal server reports version X.Y.Z-W, then the server will be satisfied that the client is up-to-date if it reports the same value as the app-version in the gateway configuration request (/ssl-vpn/getconfig.esp).

Examples of the version tag in GlobalProtect portal XML in the wild:

• https://www.spinics.net/lists/openconnect/msg05666.html
• https://www.spinics.net/lists/openconnect/msg05623.html

This should help avoid the dreadfully vague "Matching client config not found" error due to too-old client versions.

See #176 (comment 395207613) for where a user ran into such an issue previously, and !131 (merged) for where we addressed it previously by increasing the emulated GlobalProtect app version.

There don't actually appear to be meaningful differences between the GlobalProtect app versions in terms of backwards-incompatible protocol changes, so this will allow OpenConnect to Just Work™ on newer server versions that may insist on newer client versions.

Caveats:

1. The <version> tag in portal XML often contains leading/trailing space which we need to strip.
2. If the portal XML doesn't contain <version>, or if the user connects straight to the gateway interface, we still need a default emulated app-version to fall back to.
3. As with everything else GlobalProtect, the naming of this field in the wire protocol is incredibly inconsistent. It's called app-version in the gateway config request, which appears to be what servers frequently verify, but it's called client-version in the XML HIP report (even though clientVer=4100 elsewhere in the protocol).
4. Ideally, we would allow end users to override the version reported to the client when needed. That should be easy to do once we merge some form of !103.