OpenVPN: Fix handling of CNs in Client Certificates

Note: This PR solves Bugzilla issue [#10552](https://bugzilla.ipfire.org/show_bug.cgi?id=10552)

This PR fixes a few issues in the handling of OpenVPN client CNs. The main problem is that the CN is currently expected to be the last attribute in a certificate's subject string. In case the subject contains further attributes after the CN such as an `emailAddress`, the CN is incorrectly parsed, which leads to misbehaviour at a few places:

### Upload of client certificates
When a client certificate with further attributes after the CN is uploaded, the resulting entry in `/var/ipfire/ovpn/ovpnconfig` contains the CN and all other attributes separated by a slash (`/`) character. The reason is that `/srv/web/ipfire/cgi-bin/ovpnmain.cgi` executes `/usr/bin/openssl x509 -text ...` and tries to grep the CN from the output of the command. However, the `-text` option causes attributes after the CN to be appended to the CN with a slash character as separator.

**Example**
The certificate with the subject `C=XX, L=Xxxxxx, O=xxx, OU=XX, CN=ovpnClient, emailAddress=ovpnClient@example.com` will generate this name in ovpnconfig when uploaded: `ovpnClient/emailAddress=ovpnClient@example.com`

### tls-verify is not working
The script `/usr/lib/openvpn/verify` which is executed by OpenVPN during the TLS handshake parses the CN incorrecly as well. It will contain all attributes of the subject after the CN separated by a comma. Using the example from the last chapter, the parsed CN will be `ovpnClient, emailAddress=ovpnClient@example.com`. This CN is then compared with the entries in `/var/ipfire/ovpn/ovpnconfig` which will never match. As a consequence, the TLS handshake will fail with this error:

    WARNING: Failed running command (--tls-verify script): external program exited with error status: 1
    VERIFY SCRIPT ERROR: depth=0, C=XX, L=Xxxxxx, O=xxx, OU=XX, CN=ovpnClient, emailAddress=ovpnClient@example.com
    TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned


### Connection status in the Web UI
To display the connection status of the OpenVPN clients the script `/srv/web/ipfire/cgi-bin/ovpnmain.cgi` reads the correct CNs of the connected clients from `/var/log/ovpnserver.log` and tries to compare them with the (possibly wrong) CNs in `/var/ipfire/ovpn/ovpnconfig`. As a consequence, the clients will always be displayed as `DISCONNECTED` even if they are connected.

This PR fixes all the issues described above and stays compatible with previously created wrong entries in `/var/ipfire/ovpn/ovpnconfig`:
- The `/usr/lib/openvpn/verify` script will parse the CN correctly from the subject. If it cannot be matched exactly with an entry in `/var/ipfire/ovpn/ovpnconfig`, it uses a regex to match it with an eventually incorrectly saved CN.
- `/srv/web/ipfire/cgi-bin/ovpnmain.cgi` has been fixed to use the correct CN when uploading or creating a client certificate.
- `/srv/web/ipfire/cgi-bin/ovpnmain.cgi` will use a regex to match the CNs of the connected clients to the possibly wrong CNs in `/var/ipfire/ovpn/ovpnconfig`.