Don't bother with "correct" units for the pressure_time calculation

I fixed the pressure-time calculations to use "proper" units, but
thinking about it some more, it turns out that units don't really
matter. As long as we use the *same* unit for calculating the
integral, and then re-calculating the step-wise entries, the units
will cancel out.

So we can simplify the "pressure_time()" function a bit, and use
whatever units are most natural for our internal representation. So
instead of using atm, use "mbar".

Now, since the units don't matter, this patch doesn't really make much
of a difference conceptually. Sure, it's a slightly simpler function,
but maybe using more "natural" units for it would be worth it. But it
turns out that using milli-bar and seconds has an advantage: we could
do all the pressure_time integral using 32-bit integers, and we'd
still be able to represent values that would be equivalent to staying
at 24 bar for a whole day.

This patch doesn't actually change the code to use integers, but with
this unit choice, we at least have that possibility.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Do pressure-time integral using integer values

Now that the pressure_time calculations are done in our "native"
integer units (millibar and seconds), we might as well keep using
integer variables.

We still do floating point calculations at various stages for the
conversions (including turning a depth in mm into a pressure in mbar),
so it's not like this avoids floating point per se. And the final
approximation is still done as a fraction of the pressure-time values,
using floating point. So floating point is very much involved, but
it's used for conversions, not (for example) to sum up lots of small
values.

With floating point, I had to think about the dynamic range in order
to convince myself that summing up small values will not subtly lose
precision.

With integers, those kinds of issues do not exist. The "lost
precision" case is not subtle, it would be a very obvious overflow,
and it's easy to think about. It turns out that for the pressure-time
integral to overflow in "just" 31 bits, we'd have to have pressures
and times that aren't even close to the range of scuba cylinder air
use (eg "spend more than a day at a depth of 200+ m").

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Support relative times in diveplanner input "on the fly" mode

This had gotten lost when updating the profile on the fly.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>