Refactor in preparation to add ability to enable/disable individual e…

…ndpoints (#271)

A fairly large refactor of the internals. This PR separates the
implementation of the endpoint logic from the logic that exposes the
endpoint and logic that creates open api documentation for the endpoint.

I personally find this a bit easier to manage as opposed to a single
namespace inside of add_routes. There's probably a bit more changes we
could do going forward to help encapsulate logic into smaller pieces
(e.g., documentation) -- though not needed right now.

Users will not notice any changes except:

1. Feedback endpoint when disabled will return a 404 rather than a 400,
and will be hidden from documentation

Main issues:

1) If we go with a list of boolean flags which are enabled by default,
then if we decide to create additional endpoints, those will appear for
a user; an option to mitigate is to have a single variable called
`with_endpoints = ()` which will be an allow list rather than a block
list, but that could get pretty tedious. We could potentially provide
both options, giving the allow list precedence if specified.