Update HttpRules API to not have varargs with generics

[romain-grecourt]

Description

• Update HttpService interface to not be a Supplier<HttpService> to remove ambiguity

• Replace register(Supplier<? extends HttpService>... service) with register(HttpService... service)

• Overload it with 5 variants to accept up to 5 suppliers of services (@SafeVarags is not usable on interfaces)

• Add register(List<HttpService> services) for more than 5 services

• Replace register(String pathPattern, Supplier<? extends HttpService>... service) with register(String pathPattern, HttpService... service)

• Overload it with 5 variants to accept up to 5 suppliers of services (@SafeVarags is not usable on interfaces)

• Add register(String pathPattern, List<HttpService> services) for more than 5 services

Fixes #7656

Documentation

The changes are mostly compile compatible.
It's incompatible if an application was using an array of suppliers explicitly or if it was using more than 5 suppliers.

I.e.

// the method with var-arg of supplier has been removed
rules.register((Supplier<HttpService>[]) svcs);
rules.register("/foo", (Supplier<HttpService>[]) svcs);

// the method with var-arg of supplier has been removed
// it is replaced with overloaded methods with up to 5 arguments
// using more than 5 won't compile
rules.register(Svc1::new, Svc2::new, Svc3::new, Svc4::new, Svc5::new, Svc6::new);
rules.register("/foo", Svc1::new, Svc2::new, Svc3::new, Svc4::new, Svc5::new, Svc6::new);

[romain-grecourt]

@tomas-langer I'm not sure if there is much value in exposing methods that take Supplier<HttpService> ; I used the pattern of List.of, Map.of, Set.of and overloaded the methods to simulate a var-arg with up to 5 arguments. We may decide to drop the convenience around Supplier and simply remove all of the overloads.