simplify patching spec and status in reconciler (#39)

The way that we were handling patching spec/metadata and status in the
main reconciler loop was starting to get awkward and messy. We were
calling `patchResource`, `patchResourceStatus` or
`patchResourceMetadataAndSpec` in quite a few places, the main
`resourceReconciler.Sync()` code path was getting messy and hard to
read, and we were in danger of having more subtle bugs creep into the
reconciler logic because of the duplicative patch calls and non-obvious
nature of the calls.

This patch simplifies and cleans up the logic around the core
`resourceReconciler.Sync()` code paths in the following ways:

* Breaks out the create and update code paths into their own separate
  `createResource` and `updateResource` methods.
* Renames the `cleanup` method to `deleteResource` in order to match the
  create and update methods
* Removes ALL calls to `patchResourceStatus` in favor of always ensuring
  Status patching is done in the
  `resourceReconciler.HandleReconcileError` wrapper method
* Removes the `resourceReconciler.patchResource` method entirely (which
  patched both Metadata/Spec as well as Status) and ensures that the
  `createResource`, `updateResource` and `deleteResource` methods on
  `resourceReconciler` only ever call `patchResourceMetadataAndSpec`
  (since `patchResourceStatus` is now always called by the
  `HandleReconcileError` wrapper)

These changes should make the late initialize work easier to fit into
the core reconciler logic and provide a more explicit contract about
what is responsible for patching status (**only** the
`HandleReconcileError` wrapper) and what is responsible for patching
metadata and spec (the `createResource`, `updateResource` and
`deleteResource` methods).

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license.

Author: jaypipes