Consider always truncating rather than rounding up in "mul"

[PaulRBerg]

The mul function uses mulDiv18, which rounds up in case the remainder is at least 0.5:

https://github.com/paulrberg/prb-math/blob/fdb08284161bd14fb6d8a9ceceb36d181985259f/src/Helpers.sol#L213-L216

Pasting the NatSpec:

Before returning the final result, we add 1 if (x * y) % SCALE >= HALF_SCALE. Without this adjustment, 6.6e-19 would be truncated to 0 instead of being rounded to 1e-18. See "Listing 6" and text above it at https://accu.org/index.php/journals/1717.

The trouble with this behavior is twofold:

1. Runs counter to the standard behavior of Solidity, which is to round toward zero no matter the value of the remainder.
2. Creates problems for batched calculations since rounding up can lead to total amounts greater than the available amounts (see Add a version of mul/div that truncates rather than rounds #126).

Always truncating shouldn't be an issue for the vast majority of use cases. Who needs exact 18 decimal precision, anyway?

[PaulRBerg]

This would also be more in line with the behavior of most other functions in the repo, e.g. sqrt.

[PaulRBerg]

I ended up implementing this in 21fb327.

The only downside is the fact that powu function is slightly less accurate now, due to the repeated calls it makes to mulDiv18. However, we're talking very small inaccuracies, in the 16th, 17th and 18th decimals.