Re-use connectInject.consulNamespaces for API Gateway

[nathancoleman]

Background:
If ACLs are enabled and a user doesn't have identical mappings for the helm chart under connectInject.consulNamespaces and apiGateway.consulNamespaces, everything breaks. This is because the API Gateway uses a combination of both internally which results in a gateway trying to register itself under a different Consul namespace than it is authorized to.

After talking with @lkysow, we determined that these two consulNamespaces options should really be one and the same. Letting them diverge breaks many uses cases. In addition, it's cumbersome for the practitioner to have to specify both with the exact same value.

Changes proposed in this PR:

• Drop apiGateway.consulNamespaces and instead re-use connectInject.consulNamespaces for the API Gateway installation

How I've tested this PR:
Installed chart from this branch with various connectInject.consulNamespaces configurations, verifying that those values are piped through to the API Gateway controller Deployment spec just as they were previously from apiGateway.consulNamespaces.

Example

connectInject:
  enabled: true
  consulNamespaces:
    mirroringK8S: true
    mirroringK8SPrefix: "nate-"
  default: true

How I expect reviewers to test this PR:

Checklist:

• Tests added
• CHANGELOG entry added

  HashiCorp engineers only, community PRs should not add a changelog entry.
  Entries should use present tense (e.g. Add support for...)

[andrewstucki]

@nathancoleman looks like some stray empty waypoint server files accidentally got checked in.

[lkysow]

Not a big deal but for BC's it's nice to tell the user what to do. So in this case if their apiGateway.consulNamespaces is the same as their connectInject.consulNamespaces configuration, they don't have to do anything. If it's different, then they need to be aware that the connectInject.consulNamespaces will now be used.