These three intermediary types allow APIs and consumers of boxes to indicate
that they expect a particular subset of Box types. This is useful to restrict
types to what is expected, while still being able to interoperate with
APIs designed to interact with many all Box types.

For example, you can declare that a function expectes a PresenceBox to ensure
that interactors guarantee either a Full or Empty is passed. Or, you can
specify that your function returns a TryBox so callers only need to worry about
handling a Full or a Failure. Lastly, ParamTryBox allows indicating that a
given situation will only get a Full or a ParamFailure with a particular error
type.

A lot of tests and additional API conversions are required to fully bring this
vision to fruition, but this is the foundation for that work.

This allows us to make sure that we don't lose the specific type of the Box
when doing a pass operation. This was less important when the only supertype
was `Box`, but now that we can have the more specific `PresenceBox`, `TryBox`,
and `ParamTryBox`, preserving those supertypes is more important.

In particular, collect and collectFirst will always return a PresenceBox when
invoked on a PresenceBox. This is not the case for the other subtypes.

In particular, cases where each of these can guarantee a subtype of Box have
reimplementations that do so.

PresenceBox also adds a specialization of withFilter, which is used in for
comprehensions, that ensures that typing carries through.

These can now have more specific types.

Also added a blurb to the Box scaladocs regarding the Box subtypes.

Due to the way Scala resolves method overloads with implicit parameters, I
haven't been able to find a good way of defining that a TryBox that contains a
TryBox should flatten to a TryBox, and a PresenceBox that contains a
PresenceBox should flatten to a PresenceBox. Unfortunately Scala seems to
resolve the overload of flatten based solely on class hierarchy and number of
parameters, and then fails the compile if it can't plug the proper implicits
in, rather than using the available implicit evidence to choose between
overloads. Since we rely entirely on implicit evidence to know what we can do
with the contained type of the box, there's no way (that I could find) to
express diverging return types based on the contained type :(

Instead, TryBox and PresenceBox each have their own flattenTry and
flattenPresence methods, respectively, which will only compile if their
contents match the container type. This means the caller has to choose the
appropriate one to call, but at least it ensures you *can* flatten that way if
you really want to.

This spec is designed to test that Box's various methods produce the expected
resulting types.

The existing definition wasn't actually catching for all ParamTryBoxes.

Also add some scaladocs to those two methods.

We do this by dropping the concrete definitions of these two methods in Box,
preferring instead to lean 100% on late binding to resolve the correct concrete
definition of the method based on the concrete type it is being invoked on.