Add new stewadships & alerts from tree edit page.

When on the tree edit page we want add a button that allows users to add
a new stewardship or alert UDF. Users can add as many of these as they
would like. The information for the steps in the UDF is set at the time
the data for the instance comes from the API. We create an add more
button for each UDF field and then group those buttons together,
squashing them and combining their field keys for the first step. This
allow one button to handle several similar kinds of UDFs that are part
of the same collection.
Show rows when load more cell is not available.

We didn't have a case to show the stewardship and alert cells when the
more button was inactive (when there were fewer than four stewardships
or alerts in there respective sections. This change adds them.
Showing UFD collections when in edit mode.

In edit mode, we show the UDF collection data. This requires creating an
edit cell and adding it to the detail render.
Fix dates - YYYY to yyyy

The YYYY format for dates in iOS is actual a week sensitive year thus
setting a date of 2014-12-31 actually results in a date of 2015-12-31
when the application parses the dates.
Require set data to move to next step of UDF.

Users should not be allowed to click the next or done button until they
have made a selection on the current step. This enforces this behavior
by disabling the next or done button until a selection has been made.
Allow saving UDF data on new trees.

The initial data structure of new trees prevented UDF collection data
from being properly set on them. Here we capture the incoming collection
data and use it to set the proper dictionary keys so that we can add a
UDF collection to a new tree at the time we are adding it.
Surpress issue in which cells respond twice to click.

The stack of view controllers has a strange behavior and events seem to
fire multiple times in some cases. To prevent this, we null out data
when we are finished providing the notification.
Fix comment.
Allow for editing existing alerts.

UDF collections can be edited if they have a step that has the "default"
key. If they do not, they will show but will not have a click callback.
Right now this is only true for alerts. If a UDF has the default key for
one of its steps, that step will be the only editable value. We presume
that there can only be one default. This also means that we need to set
a temporary id on new alerts so that we can edit those without making a
new one. The temp id must be removed prior to saving the data.

Since we need to find the updated UDF and swap out its data prior to
saving, we can't just pass back a single value, we need the entire data
object for the UDF, this means that we need to pass that into the
controller and the reset it on the tree model. To do this we provide
another paramter on the click callback of the cell which allows the
existing data to be sent in and altered.
Auto set the default case on new alerts.

Alerts provide a data key that species their default value. The case for
this is that alerts should always start as unresolved and then later be
marked as resolved. In order to deal with this, we inspect the incoming
data and then hop over the step in the UDF that has a default value and
set the default for the new UDF.
Adding human labels to add more cells.

We need to translate the UDF keys to human readable labels so
tree.udf:Alert needs to be "Tree" and plot.udf:Alert needs to be
"Planting Site." We create an array that matches the incoming UDF key
choices in length and uses a dictionary to set human readable values.
Using the two arrays and their indexes it is easy to know which machine
value to pass to the API and which label to present to the user.
Move common functions to static helper class.

Non-editable udf collection cells and editable udf collection cells
share a good deal of code. A few of their methods are very similar and
some were identical. To DRY this up, we create a helper class that
provides the shared code as static functions.

Additionally, some comments were added and some unused code was removed.
Move UDF collection cell code to new files.

The code in the OTMDetailCellRenderer files was becoming overwhelming so
all the UDF collection code was moved to new files to ease future
development tasks.

Also rename some methods to be more idiomatic and descriptive.

Add some comments.
Cleanup xcode warnings.

The line removals represent unimplemented methods or variables.
Add simpler initializers.

Create a helper initializer that calls to a more verbose initializer so
that we don't have to pass a bunch of nil values in from calling code.
Rename prepareDiscreteCell.

Renamed prepareDiscreteCell to prepareCellSorterWithData as the latter
is more descriptive of what the method actually does.
Use constants for date strings.

Since our date strings are used in many places, it will be annoying if
an API change forces us to go through many files altering strings to
deal with an update. Instead we set a constant on OTMEnvironment that
supplies the most used data strings throughout the application. We all
fix a quoting issue on date strings which had an extra ' at the end.
DRY up more code with helper function.

Move some more code that is duplicated and can be sped up and condensed
into the helper class.