Helper functions for working with datomic entities.

Transaction results are put in `:result` in the liberator context.

Conforms endpoint response bodies to the format that the frontend expects.
The Sweet Tooth frotend expects responses in the form of

`[[:entity {:ent-type {ent-id {:entity :map}}}]]`

The vector `[:entity ...]` is a segment. A response contains 0 or
more segments. This format was chosen to better support composition
in responses: If you need to add more information to a response, you
can add a new segment without concern for what the response already
contains.

However, it would be tedious to have to format the response body of
every single endpoint this way, when most the time you just want to
return one or more entities. You should be able to just return the
entities; this namespace lets you do that.

Basically, returning a map or vector of maps is shorthand for the
full entity segment.

Includes:

* Utility functions for retrieving common values from the
context (`record`, `errrors`, `params`)
* A template of decision defaults appropriate for an SPA
* Utility functions for auth

Introduces loose convention of putting a record under `:record` in
the context

Extends liberator's representations to handle transit

Module for creating a ring router (a function that receives a ring
requests and dispatches to a handler function based on the request's
URL). It ties together the sugar for defining reitit routes and
liberator handlers.

The module uses routes produced by
`sweet-tooth.endpoint.routes.reitit/expand-routes`. These routes
contain metadata that allow the module to look up vars that define
liberator handlers. The module is responsible for associating routes
with handlers.

The module is also responsible for adding each handler's
configuration to the system's integrant configuration, reducing
boilerplate for the developer.

We derive handler keys from `::handler`. We then define
`ig/init-key` methods for those keywords, where the method returns a
handler function.

This module serves Sweet Tooth's goal of reducing the boilerplate
required to get a system running, reducing the potential for errors
and allowing the developer to focus on what's unique to their
application.

Pagination utilities

Sugar for reitit routes. Lets you:

1. Specify a map of options that apply to a group of routes
2. Transform names (usually namespace names) into reitit
routes that include both:
   2a. a collection routes, e.g. `/users`
   2b. a unary route, e.g. `/user/{id}`


## Basic expansion

A sugared route definition might be:

[[:my-app.endpoint.user]]

This would expand to:

[["/user" {:name   :users
             ::ns    :my-app.endpoint.user
             ::type  :collection
             :id-key :id}]
 ["/user/{id}" {:name   :user
                  ::ns    :my-app.endpoint.user
                  ::type  :member
                  :id-key :id}]]

## Common option map

Here's how you'd apply a map of options to many routes:

[{:ctx {:foo :bar}}
 [:my-app.endpoint.user]
 [:my-app.endpoint.post]

 {} ;; resets "shared" options to an empty ma
 [:my-app.endpoint.vote]]

This would expand to:

[["/user" {:name   :users
             ::ns    :my-app.endpoint.user
             ::type  :collection
             :ctx    {:foo :bar}
             :id-key :id}]
 ["/user/{id}" {:name   :user
                  ::ns    :my-app.endpoint.user
                  ::type  :member
                  :ctx    {:foo :bar}
                  :id-key :id}]
 ["/post" {:name   :posts
             ::ns    :my-app.endpoint.post
             ::type  :collection
             :ctx    {:foo :bar}
             :id-key :id}]
 ["/post/{id}" {:name   :post
                  ::ns    :my-app.endpoint.post
                  ::type  :member
                  :ctx    {:foo :bar}
                  :id-key :id}]

 ;; vote routes do not include the :ctx key
 ["/vote" {:name   :votes
             ::ns    :my-app.endpoint.vote
             ::type  :collection
             :id-key :id}]
 ["/vote/{id}" {:name   :vote
                  ::ns    :my-app.endpoint.vote
                  ::type  :member
                  :id-key :id}]]

Introduces some conveniences for dealing with duct systems:

* A multimethod `config` for naming integrant configs, like `:dev`,
`:test`, etc.
* An `ig/init-key` alternative that allows a component's *configuration*
  to specify an alternative component implementation, possibly bypassing
  the `ig/init-key` implementation entirely
* `replacement` and `shrubbery-mock` alternatives

A way to run integrant components as a task. Maybe not a great idea?
Used for things like creating a db or running migrations.

Includes:

* Macros and a fixture for dealing with a system for the duration of a test
* Helpers for composing and dispatching requests
* `read-body` multimethod for parsing response bodies of different types (transit, json etc)
* assertions that work with response segments

not production ready