Maximize common unit for `QuantityPoint`

[chiphogg]

Consider this test, from :quantity_point_test:

TEST(QuantityPoint, CommonPointUnitLabel) {
    EXPECT_THAT(stream_to_string(celsius_pt(0) - kelvins_pt(0)),
                AnyOf(StrEq("5463 EQUIV{[(1 / 20) K], [(1 / 20) degC]}"),
                      StrEq("5463 EQUIV{[(1 / 20) degC], [(1 / 20) K]}")));
}

This passes... but only because we're using non-standard and optimized definitions for Celsius and Kelvins in that file. The actual code on Au 0.4.1 gives "27315 EQUIV{[(1 / 100) degC], [(1 / 100) K]}". Yes, it's a little easier to recognize the correct value, but it's also a factor of 5 bigger, which means unnecessary additional overflow risk.

We could try manually specifying every origin in the most efficient units. However, this is a losing game, because we would need to consider all pairwise combinations of multiple units --- what's going to happen when we bring Fahrenheit into play?

My first attempt to solve this was to store the origin difference in a unit where its value was 1. I was worried this wouldn't be possible at compile time, but since the origins are constexpr quantities, it actually is! The problem with this is that such a big unit hits our overflow safety surface pretty easily. But if it's possible to construct this unit in the first place (and it is), then it should be possible to use a Constant, and take advantage of its perfect conversion policy!

This is what I think we should do. I've done enough exploring to convince myself that this is possible. We're blocked on negative constants, though, and that has a lot of implications we'll need to work through.