Improve api consistency about tapir

[adamw]

I feared that too many of these combinators might be confusing :) But first, some motivation on why there are two ways to group parameters in the first place. I want to support two scenarios:

1. creating a description of (possibly multiple) input (output) parameters which can be re-used in many endpoint descriptions. For example, quite often you have paging & limit parameters grouped in listing APIs. You can represent this as: val paging = query[String]("start") and query[Int]("limit") and use it in many endpoints

2. creating re-useable endpoint descriptions, which can be specialized. For example, in your API all endpoints might have a path which starts with /api and upon error, return a ErrorInfo JSON. You can represent this as: val baseEndpoint = endpoint.in("api").errorOut(jsonBody[ErrorInfo]) and use it as a base endpoint for all other endpoints.

Given the tradeoff between less ways to group parameters and supporting the two use-cases above, I pick the second option.

However, we might still simplify the usages of and, / and &. Maybe it would make sense to drop &, and define / only for paths, that is on PathCapture and PathSegment, not on all EndpointIOs?

[adamw]

In the end keeping and and / as ways to combine inputs is as much as I could get - essentially dropping &. Any other suggestions welcome :)

[adamw]

Closing as "won't fix" for the reasons above. Feel free to reopen if you've got new ideas :)