Always return Quantity, not raw numbers (breaking change)

[chiphogg]

Right now, the result of a Quantity computation whose unit is equivalent to 1 is a raw number, rather than a Quantity equivalent to unos. I made this decision because people generally expect this kind of computation to produce a raw number. We do provide implicit convertibility to the raw number type, but this can sometimes fail to trigger. Experience shows that the only thing that always acts like a raw numeric type is that type itself.

I believe that further experience has shown this to be a mistake. It makes generic programming too hard. I used to think this was fine, because generic programming is mainly the domain of more experienced users, who will know how to handle this. I was wrong: the reason it's still a problem is that users can't be confident whether they'll get a Quantity or raw number just from inspecting a computation. If we refactor and change the unit of one of the participating quantities, it can even switch from one to the other!

The way to solve this is to provide some idiomatic function --- say, as_raw_number(...) --- which "unpacks" a dimensionless quantity. This helps other (non-unity) dimensionless use cases, too. Alternatively, we could just tell everyone to write .in(unos).

This is a breaking change. The best time to do this would be when we're nearly ready to release 0.4.0. We will also need to use Aurora's AV repo to see how "bad" this change would be in terms of what it does to the code.

[jaredjxyz]

+1 for this change... There are certainly tradeoffs, but I'll also add that this could unlock the ability to create more dimensionless units - for example, .in(dozens), .in(bakers_dozens)

[chiphogg]

One slight complication to consider is that some users might have functions that are generic not just across different Quantity types, but also between Quantity types and raw numbers (and possibly other types). See #248 for an example.

This means that .in(unos) probably won't work. However, we could design the as_raw_number(...) API so that:

• it returns its argument for anything other than a Quantity
• it returns the value in unos for a dimensionless Quantity
• it produces an error for any other type of Quantity