Correct job base heartbeat calculation

The "how many buckets ago did we last run" calculation was wrong, in a
way that was too aggressive about throttling execution.  We no longer
use a per-job base runnability milestone; instead, the app as a whole
experiences runnability intervals every so often based on its standby
state.

We also now specifically allow for newly-scheduled jobs within the app's
standby-defined execution slot to run within that slot, rather than
having to wait for the next one.

A small stats bug has been fixed in the job-start code: we would
previously log a job start event in battery stats even when the intended
job turned out to be unlaunchable.

Finally, there's a new 'heartbeat' shell command that allows a tester
to read or advance the standby heartbeat.

Change-Id: Icf03f82e2fde7408095f6d06642d944c3ae10a26
Fixes: 72713333
Test: atest CtsJobSchedulerTestCases