Update the example to expose the service in TLS Client Certificate Validation to be consistent with the operator deployment

When upgrading to 2.11 the httpsPort field in the APIManager CRD should be used. Refer to THREESCALE-8039. When updating the APIManager with the httpsPort: 8334 the Service is updated with a named port/target port httpsproxy automatically.

However there is an inconvenience for customers: the old routes, since they were created manually because the self-managed option is needed to configure TLS, have a target port named "https" (or any other name of their choice) as suggested in our documentation in the patch command of the service:

$ oc patch service apicast-staging -p '{"spec":{"ports":[{"name":"https","port":8443,"protocol":"TCP"}]}}'

So when upgrading, new routes will have the target port named httpsproxy and work correctly but the target port for the old routes has to be updated manually from the named  port "https" to "httpsproxy".

The request is to update the example in the current documentation and use the same convention httpsproxy so that customers won't have to update the named port manually.

$ oc patch service apicast-staging -p '{"spec":{"ports":[{"name":"httpsproxy","port":8443,"protocol":"TCP"}]}}'