My current thinking on handling the regex, is that in the only case we use it, we are using it to abstract multiple different endpoints into 1:

/api/search/general
/api/search/interact
etc...

While that's a programming abstraction, I don't think it's best to abstract that representation to UI-side docs, so lets rather think about how we can represent all the different search endpoints in the docs. Here are some ideas:

1. Despite being a regexp, there is a deterministic structure: `/api/search/<name>/<unstructured/path/params>`. For each `name` that is registered with search, it can register a new regexp search endpoint keyed off of the `name`, so we will have one search endpoint per search registered. When registering a search using `SearchAPI.registerSearch`, make it so that it can take in additional parameters that describe its schema. There is still a question on how to handle the regexp path that comes in for each individual search endpoint. My thought is that if the `path` is regexp, you can have a `pathAlias` property that describes in "non-regexp-form" what the path structure looks like, and that pathAlias value could somehow be communicated by the one providing the search.

2. Make it so you can register some sort of meta endpoint that just registers some docs with no real endpoint, also make it so that we simply never register an endpoint with a regexp path to swagger.

WDYT?