Add coercing versions of conversion functions

[chiphogg]

These are variants of .as and .in for both Quantity and
QuantityPoint. When we precede these with the "coerce" vocabulary
word, they become forcing, ignoring the safety checks for truncation and
overflow.

This new syntax has two major advantages over the explicit-Rep version.
First, it makes the intent clearer. Second, it stops forcing users to
repeat the rep when they want the same rep they started with, which I
think is the usual case. (Thus, without these APIs, explicit-rep
obscures intent: one never knows whether the author wanted a cast, or
wanted to bypass the safety checks.)

It also unlocks another, later improvement: we will be able to extend
the safety checks to the explicit-rep versions! But we won't attempt
that for a while because that's a breaking change.

There may be other APIs that would benefit from using the "coerce"
vocabulary word instead of explicit-rep. However, we'll start with just
these, both because they're the overwhelmingly most common use case, and
because it gives us a chance to try out these ideas in practice for a
while.

To test this PR, I added new unit tests to cover all of the use cases.
I also rendered the docs locally and checked that the links worked as
intended.

Helps #122.

[geoffviola]

The API changes look good. I like that the truncation/overflow at runtime is enabled with a longer, explicit name like static_cast. Also, it's nice not to have to repeat the rep in doing a conversion. The tests cover truncation and overflow for quantity and quantity point. The docs changes seem good.