Fixed Chronometer Time Calculation

Fixed up the looping algorithm for determing the current time from the
string of the chronometer. Was starting at the wrong end of the list and
then sending the opposite of what I wanted to do for the pow function.

Also fixed up the string being sent to the database to be a long for
clarity, and then in storage it's transformed into a string and saved.
We could try to use a numeric or integer type to store the long epoch
value, but suggestions on SO suggest otherwise due to precision.

You can still break the chronometer (not the application though) by
going to the third tab, then back to the first, then back to the third
then back to the first. You'll be counting in ascii for a bit before it
corrects itself. I'm _really_ not sure what the hell it's doing. At
first I was thinking that perhaps it's interpreting the characters as
integers and playing with just that. But, the ASCII value for 0-9 are
0-9... it's how integer conversion works. So then maybe I thought that
it's counting past 9 up to the next ascii value, but 10 is \n and 11 is
vertical tab so that can't be it and most values in that range are
random escape characters anyway. So I'm not sure why it counts with: , /
) ( until it finaly fixes itself. Strange strange...

Fun fact though, the actual time calculation is still correct during
that time, it's just the display that is wrong. And I think the problem
might be in the onClickListener because the 'stupid chrono' log displays
the correctly formatted date. Intriguing!
Merge branch 'android' of github.com:EJEHardenberg/GreenUp into android
Working on state of the chronometer being persisted

It works if you:

turn on the chronometer, exit the application (from p1)
- you'll still have a beating clock

It doesn't work if you:

turn on the chronometer, goto p3, go back to p1