Support IPv6

Is your feature request related to a problem? Please describe.
We'd like to use Pinniped in IPv6 Kubernetes clusters. I'm opening this issue to track things that need to be fixed for Pinniped to work on IPv6 environments.

After testing Pinniped within an IPv6 cluster, here is a list of things that we have come across.

• Pinniped-supervisor does not honor the HTTP_PROXY/HTTPS_PROXY/NO_PROXY environment variables. This is not directly an IPv6 issue, but in our testing we were required to use a proxy to use some IPv4 services.
  • The upstreamwatcher creates a client with a new http.Transport and it doesn't set many of the fields the DefaultTransport sets. Important to us is the Proxy field, but it may also be valuable to set many of the other fields the DefaultTransport sets, such as Timeout fields.
• Certain areas of the pinniped codebase assume that if an IP address is provided it is an IPv4 address. For example, a quick search for splitting on colons results in things like this. It isn't reliable to split on colons because IPv6 uses colons as a delimiter.
  • Golang does have a helper function that could be used instead: net.SplitHostPort.
  • We didn't end up hitting this case ourselves because we have been using FQDNs in most places, which seems to work. So a deeper search may be required to root out all the places were we assume an IP address is an IPv4 address.
• The pinniped cli hardcodes the 127.0.0.1 localhost address as the callback listen address.
  • This may not be a big deal because users of the pinniped cli should be able to bind to an IPv4 loopback address on their machines, even if they are working with an IPv6 only Kubernetes environment.

Are you considering submitting a PR for this feature?
Yes

• How will this project improvement be tested?
  It seems like it would be valuable to have an E2E test(s?) that could run on a Kind cluster that has been deployed as an IPv6 environment. Open to any suggestions here for additional things to test.

• How does this change the current architecture?
  It shouldn't. This is just fixing parts of the codebase that assumed IPv4 addresses and honoring the proxy environment variables.

• How will this change be backwards compatible?
  It should still support IPv4.

• How will this feature be documented?
  Not sure if any additional documentation is necessary other than saying IPv6 is now supported. Open to any suggestions here.

Start with internal/controller/supervisorconfig/upstreamwatcher/upstreamwatcher.go and internal/controller/supervisorconfig/tls_cert_observer.go, then locate the pinniped CLI callback listen address. Check how proxy environment variables, host-port parsing, and loopback binding are handled, and review the proposed Kind IPv6 E2E coverage. Done means the identified IPv6 cases and proxy behavior work without breaking IPv4.