Allow path parameters to be specified as security inputs (Tapir)

Sometimes, the [security logic](https://tapir.softwaremill.com/en/latest/server/logic.html#re-usable-security-logic) of an endpoint needs to get access to path parameters. For example, the [product search endpoint](https://github.com/commercetools/search-services/blob/44a98f1cd0205d53d505c60824474a960d5049ca/service/src/main/scala/com/commercetools/search/impl/service/SearchServiceImpl.scala#L317-L325) (`/:projectKey/products/search`) security logic checks that the API token provided by the client actually has the permission to read products off the `:projectKey` path parameter.

Currently, this kind of checks can't be implemented cleanly by using code generated by this generator, because path parameters expressed as both security inputs and normal inputs don't care about each other. For example, this endpoint definition (for the product search endpoint described above):

```scala
endpoint
.post
.in(path[String]("projectKey") / "products" / "search")
.securityIn(path[String]("projectKey"))
```

Actually matches **`/:projectKey/:projectKey/products/search`**.

To work around this problem, we currently employ [`extractFromRequest`](https://tapir.softwaremill.com/en/latest/endpoint/ios.html), but we consider this solution pretty much an hack.

To properly support this use case, we could instead:

1. Either leverage a setting in the build definition, which flags a path parameter as a security input for certain endpoints. Something along the lines of `scramlSecurityInputs = Map("/:projectKey/products/search" -> "projectKey")`, or
2. Parse the [security scopes](https://github.com/commercetools/commercetools-api-reference/blob/13bf36cccabb3b757c4d978f05f4a06fb24786d8/api-specs/api/securitySchemes/oauth2.raml#L29) of an endpoint, and include the matching path parameters as security inputs instead (when present)