fixes #725

It seems that the manifest code was mapping binding.Port" to the field "containerPort" inthe KubernetesManifestGenerator`
As I have, for now, a limited understanding on that, There might be other underlying reason that I'm missing here

Adding back context from the Issue here for review:

From @jongio
#725 (comment)

Here's what I recommend:

If tye.yaml has containerPort, then use it for both containerPort in the deployment and targetPort in the service
If tye.yaml doesn't have containerPort, then use 80 for http and 443 for https for both containerPort and targetPort.

I personally do not see a scenario where containerPort or targetPort should be equal to port

@jkotalik to confirm the logic above, but @tebeco if you want to take a stab at updating to that, you are more than welcome to mod your PR.

This PR only covers HTTP scheme and not HTTPS due to the current absence of support yet for HTTPS :

                        if (binding.Protocol == "https")
                        {
                            // We skip https for now in deployment, because the E2E requires certificates
                            // and we haven't done those features yet.
                            continue;
                        }

What troubles me ?
tye.yaml seem to have the notion of port binding that seems to be used for local run when doing tye run
What happens when there's a port: 1111 specified but no containerPort ? Should it default to 80 ? or should it use the existing/defined port ?
eg:

name: foobar
services:
- name: thewebapione
  project: src/TheWebapiOne/TheWebapiOne.csproj
  bindings:
    - port: 1111
      protocol: http

This would feel like a dup to have to do:

name: foobar
services:
- name: thewebapione
  project: src/TheWebapiOne/TheWebapiOne.csproj
  bindings:
    - port: 1111
      protocol: http
      containerPort: 1111