Add ability for image_to_live to control most of dev_servers abilities.

Add ability for image_to_live to control most of dev_servers abilities.

Before this change, image_to_live could only be used by either passing a custom URL
or using the latest built image.  I've added the following:

- Ability to update from an image.zip
- Ability to update from a specific image.
- Ability to clobber the stateful partition after an update
  (excluding /usr/local and /var)
- Ability to customize and capture both the update and devserver logs.
- Ability to see the progress of an update.

I've also modified the start logic.  It seems the update_engine can get in a state
where if you fail a previous update by killing the devserver, the update engine
will hang for a long time (retries a lot).  So I've changed the behavior of
startup and detecting that the system isn't ready to update, to be, reboot and
then try the update.

BUG=
TEST=Tested with all options.

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=c5a2038

[kmixter1, 2010-09-16 23:55:55]

LGTM

http://codereview.chromium.org/3389009/diff/2001/3001
File image_to_live.sh (right):

http://codereview.chromium.org/3389009/diff/2001/3001#newcode16
image_to_live.sh:16: DEFINE_string server_log "dev_server.log" \
abc order?

http://codereview.chromium.org/3389009/diff/2001/3001#newcode69
image_to_live.sh:69: function reintrepret_path_for_chroot() {
misspelled here and at call point.

http://codereview.chromium.org/3389009/diff/2001/3001#newcode192
image_to_live.sh:192: echo -n "." && sleep ${timeout}
why &&?

http://codereview.chromium.org/3389009/diff/2001/3001#newcode212
image_to_live.sh:212: status_thread &
I probably would have instead backgrounded the blocking call and used the status
updates (in the main thread) to determine when it finished - possibly killing
off the backgrounded thread if necessary remotely, but I guess this is
equivalent.