Fix pekko route naming

[samwright]

There are a few problems with the http.route values generated in pekko's instrumentation.

1. Path matching does not need to end with a PathEnd matcher, as the current solution assumes, e.g.:

pathPrefix("foo" ~ not("bar")) { complete("ok") }

will match /fooabc/123, but no http.route is generated. Given the glob-style approach of using * to represent a captured variable, I suggest the correct http.route here should be /foo**.

2. pathPrefix doesn't work as expected, e.g.

pathPrefix("a") {
  pathPrefix("b") {
    path("c") {
      complete("ok")
    }
  }
}

will match /a/b/c, but the http.route generated is abc.

This solves those issues, and adds a variety of PathMatchers to the tests.

[laurit]

will match /fooabc/123, but no http.route is generated. Given the glob-style approach of using * to represent a captured variable, I suggest the correct http.route here should be /foo**

I personally would prefer /foo* to /foo**

[samwright]

I went back to using PekkoRouteHandler from the Tapir instrumentation, since this lets people combine pekko path-matching with tapir path-matching. I doubt there's a good reason anyone would do that, but it was working before this PR so I shouldn't break it. I added a test to confirm.

[samwright]

This seems to be the only way to get the Uri.Path.Empty object from java - apparently once it's 3 or more levels deep, accessing nested scala classes from java gets tricky.

[samwright]

@laurit @masonedmison any other comments?