Finish writing QuantityPoint reference

We take the `Quantity` reference as a template, and adjust the contents
accordingly.

Many sections can be omitted.  For example, we don't support
multiplication or division, and there is no "corresponding quantity
point" machinery at this time.

Other concepts are unique to `QuantityPoint`.  For example, addition and
subtraction always involve both `QuantityPoint` and `Quantity`.  Also,
there are further restrictions on implicit conversions in the case of
units with offset origins that can't be represented as integers.

A few other docs got updated as well.

- Fixed a typo in the `Quantity` reference.
- Added a link anchor in the `Unit` reference.
- Added a section on quantity point makers in the unit slots discussion.

To test this change, I clicked on every link and made sure it went where
I was expecting.

I also opened the `Quantity` and `QuantityPoint` reference docs in two
neighboring tabs, and clicked on every corresponding section one at a
time, tabbing back and forth to see the changes.

Fixes #140.

docs/discussion/idioms/unit-slots.md

@@ -57,6 +57,16 @@ they have two advantages that make them easier to read:
 2. You can use grammatically correct names, such as `meters / squared(second)` (note: `second` is
    singular), rather than `Meters{} / squared(Seconds{})`.
 
+#### Notes for `QuantityPoint`
+
+`QuantityPoint` doesn't use quantity makers; it uses quantity _point_ makers.  For example, instead
+of the quantity maker `meters`, it uses the quantity point maker `meters_pt`.
+
+The implications are straightforward.  If you have a `QuantityPoint` instead of a `Quantity`, then
+use the quantity _point_ maker instead of the _quantity_ maker.  The library will enforce this
+automatically: for example, you can't pass `meters` to a `QuantityPoint`'s unit slot, and you can't
+pass `meters_pt` to a `Quantity`'s unit slot.
+
 ## Examples: rounding to RPM
 
 Let's look at some examples, using this quantity variable:

docs/reference/quantity.md

@@ -265,7 +265,7 @@ slots](../discussion/idioms/unit-slots.md) discussion for valid choices for `uni
     `int`.
 
     The above example used the quantity maker, `inches`.  One could also use an instance of the unit
-    type `Inches`, writing `length.as(Inches{})`.  The former is generally preferable; the latter is
+    type `Inches`, writing `length.in(Inches{})`.  The former is generally preferable; the latter is
     mainly useful in generic code where the unit type may be all you have.
 
 **Without** a template argument, `.in(unit)` obeys the same safety checks as for the [implicit