Invoke a stable 'git status' command to check for cleanliness.

Git 1.8.0 changed the format of 'git status' from

    ... (working directory clean)

to
    ..., working directory clean

This kind of harmless modification of prose output happens pretty regularly,
and relying on the prose parts to determine the result of a Git command is
pretty fragile.

Fortunately, Git folks are aware of this, and provide stable interfaces too.
For 'git status', the programmatic interface is 'git status --porcelain',
which has a stable (and much simpler) output format, with one line per
non-clean file. Empty output indicates a clean tree.

I haven't spent a huge amount of effort finding other places this might bite;
with this change git-deploy works (to the best of my testing, which isn't much)
on Git 1.8.0.

Note we cannot just use `git status --porcelain`'s output to report to
the user, as it would produce some ugly output:

    :)owen@Dashie:example (master)$ git deploy start
    # FATAL: working directory not clean. git status reports:
    # FATAL: ?? .deploy
    # FATAL: ?? foo
    Died at /Users/owen/Development/git-deploy/git-deploy line 45.

Se we use `git status --porcelain` for checking the cleanliness of the work tree,
but `check_if_working_dir_is_clean` once again returns non-`--porcelain` output,
returning the UI to a sensible state:

    :(owen@Dashie:example (master)$ git deploy start
    # FATAL: working directory not clean. git status reports:
    # FATAL: On branch master
    # FATAL: Untracked files:
    # FATAL: (use "git add <file>..." to include in what will be committed)
    # FATAL: .deploy
    # FATAL: foo
    # FATAL: nothing added to commit but untracked files present (use "git add" to track)
    Died at /Users/owen/Development/git-deploy/git-deploy line 45.

Putting the second call inside of `check_if_working_dir_is_clean` keeps the changes
pretty localized, even though this sub only has one caller.

Note that there is not much point in "optimizing" this code, for
instance by rolling our own "pretty" status mode: the file system will
be hot after the initial status, and the second should be quite fast as
a consequence.

Committers Note: This is a rebased/squash of two commits, with edits to
the message. Also, the code this patch refers to predates the options this patch
uses to fix things, which is why it wasn't used in the first place. -- Yves
Untangle issues with END blocks, and exit codes (introduce fatal_exit)

When $? is set inside of an END block it changes the exit code returned
to the OS. (See the docs for $? in perlvar.)

We were calling routines that would execute system/backticks inside of
an END block in Git::Deploy::Timing, which would clobber the exit code.

Various patches ensued to try to work around this fact, but ultimately
confused the matter more. This patch effectively reverts those patches,
and makes it so we get configuration for Git::Deploy::Timing at startup
and not shutdown, thus leaving the exit code alone during teardown.

This patch also introduces a new sub exported by Git::Deploy::Say called
fatal_exit($code,@msg) which is intended for top level routines to use for
fatal exits which should return a specific exit code. Internal routines
should continue to use _die() as it is trapable wheras fatal_exit() is
not. In the long run we need to rething this separation of
functionality.