fix(parser): add HTTPRoute combined services routes

[jrsmroz]

What this PR does / why we need it:

Add support for combined service routes when parsing gw api HTTPRoutes. Rules from HTTPRoute are grouped under matching set of backend references.

Which issue this PR fixes:

Part of #2881

Special notes for your reviewer:

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

[rainest]

Well, this response ended up being much longer than I wanted. The short version:

• Multiple rules that use the same Service and Filters should result in a single route with multiple paths.
• We should have combined test cases for multiple multi-Service backends, some which are equal and some which are not (rule 1:serviceA,serviceB, rule 2: serviceA,serviceB, rule 3: serviceA, serviceC).
• We should have tests for backends with Namespace set (to something other than the route namespace) and multi-Service backends where one or more entries has Namespace set. This is less because I'd expect it to break and more to just have a clear before/after example--working forwards through the code to determine the output is complicated for HTTPRoute.

---

Having the separate combined test cases makes it clearer why I was confused earlier--the comment about having separate test cases was less to simply make them separate tests, but rather because the two variants should not produce compatible outputs. If we were getting the same outputs for both, that should point to an issue with the combined translation not doing what it should, but I wasn't sure what.

These two rules which share a service, should not produce these separate routes, but rather a single route with both /httpbin-1 and /httpbin-2 paths.

Unlike Ingress (where modification annotations apply to all rules), HTTPRoute Filters can apply modifications per rule. These should all require plugins, and thus require different routes, so if the rules have different Filter sets, we won't be able to combine them.

For comparison, a similar Ingress test rule set results in a single route with many paths, whose name indicates the Service those paths target. Ingress consolidation also has to check for equal hostnames, but that's part of the spec, not rules, in HTTPRoute and we don't need to worry about it for HTTPRoute consolidation.

Combining those should inherently de-duplicate Services since there's not more than one route using a given Service.

I forget why we were even generating those separately per HTTPRoute rule to begin with--I guess we had to name them per rule for multi-Service backends and then used that logic for all HTTPRoute Services, rather than the traditional namespace.name.port convention.

I thought we would be able to use the traditional for single-service backends when consolidated, since multi-service backends would be de-duplicated to a single instance. However:

• this is inconsistent with the Ingress equivalent, which uses Ingress info in the service name. I forget why we needed to do this.
• my namespace.name.multi-0.xx attempt at stuffing multi-Service into that format doesn't work well if the Services are in different namespaces.

Given that it's the status quo and the ambiguity around Services in other namespaces, continuing to use the first rule number the Service set appears seems fine for that--there's unfortunately just not really a good way to put the Service name in consistently.

[jrsmroz]

@rainest It's not that simple.

Multiple rules that use the same Service and Filters should result in a single route with multiple paths.

If we consolidate the rules to that degree, we need to take into consideration the method and headers hidden in the HTTPRouteMatch too. They may differ between HTTPRouteRule instances.