Fix round to 0 or 1 in capacity computation with given full-at

[akobel]

Fixes #666: static_cast<float>(capacity / full_at) is either 0.0 or 1.0 for most sane values of full_at.

I'm not 100% sure of the logic, though: clamping capacity to 0 .. full_at might be reasonable for defective batteries, if and only if full_at is well-known and can never be exceeded, and capacity readings are error-prone and could be misleading if higher than full_at.
I'd prefer the interpretation that capacity should not be clamped, but that I simply consider my battery to be charged at, say, full_at 80. In fact, that's what I set as a regular charging threshold to conserve battery lifetime, unless I prepare for extended offline periods and manually request 100%-charging. But my battery is nevertheless perfectly able to charge up to 100%, and I'd prefer this to be reflected by showing the actual capacity... But that's a matter of taste.

Why not leave full_at at the default 100 and just change the "good" threshold then? Well, reason is that my battery (again, usually) won't charge beyond 80%, and the "time-to-full" should reflect the fact that "full" is 80% in this context. Of course, this is not taken into account (yet), so I can just as well do without full_at.
In full generality, it's even more complicated: e.g., modern Thinkpads have a hysteresis function that sets lower and upper charging thresholds: target 80% as full, but don't even bother to start charging unless the battery drops below 75%. Hence, time to full would be time to 80%, if coming from less than 75%, or NaN/inf/undef if the cable has been plugged in between 75 and 80%...

If that's something you'd consider worth to add in the long run, I might investigate.

[Alexays]

Thanks!

[akobel]

My pleasure, thank you. Any opinions regarding my comment for the full_at logic? As mentioned, I might give it a shot, but only if there's upstream interest. It's already well-usable as-is, so not one of my priorities...