connect/docs: clarify service.port for each context

[shoenig]

The group.service.port value serves more than one purpose, given the context of the service. This has lead to some confusion, particularly when setting up connect services where folks sometimes incorrectly (out of habit) use a port label instead of directly setting the numeric port.

I suspect we could emit a warning (or even error?) on job submission when a connect sidecar-using service sets the service.port value to a label instead of literal port.

If the docs had a table under the service.port parameter, we could describe what is expected in each context, e.g.

service kind	port value
normal	numeric or port mapping label
uses connect sidecar	numeric
ingress gateway	port mapping label (optional)
terminating gateway	none (optional)
mesh gateway	external port mapping label