Proposed fixes for ACPI backend

[Ryan Lortie]

Hello Everyone.

As per:
 http://bugzilla.gnome.org/show_bug.cgi?id=315259

I created a patch for gnome-applets in hopes that the 2.12.0 release
would provide a workaround for this problem.  The release team, however,
appears to not want to push the changes into the release at such a late
date (and I don't blame them -- I'm only 5 hours away from rolling the
final tarball).  One of the release team members suggested that the
correct place to fix this bug is in HAL and he's right.

HAL allows the reported charge to exceed the reported 'last full'
causing the battery status applet to show 204%.  Again, this is the
fault of crackrock ACPI implementations but it's something that HAL
should be able to deal with.

I fixed this in acpi.c and at the same time I made some other fixes:

  - The fix mentioned above to clamp current capacity to never exceed
    full.

  - A fix to make sure that the voltage used to perform the calculations
    on current capacity never exceeds design voltage.

  - A fix to battery_refresh() to make it match the checking that
    was already being done in battery_refresh_poll() (sorry that I
    missed this in my last patch....)

  - A fix to ensure that if design voltage is unknown then we also never
    use current voltage (even if we know it!).  This is important to
    avoid having our current charge level vastly exceed the design
    capacity (which will have been calculated using 1mV).

  - Variable rename to indicate that the quantities that we're dealing
    with are not mWh but rather can sometimes be µWh (or even just mAh
    in the case that we don't know voltage and just multiply by 1).

As with all ACPI changes, my work is *completely* untested (since I
don't have an ACPI laptop) so please review thoroughly :)

Cheers.