Address nested-translation errors + refactor

In an effort to discover the nested errors that can/do occur in [Riak's schemas](https://github.com/basho/riak/issues/590), this substantially refactors the code in `cuttlefish_generator`.

**This PR targets `develop` but should also be backported/merged to `2.0` branch for the next patch release.**

One source of the problem (as shown in the backtrace in basho/riak#590) was that "extended" datatypes that failed to parse halted all attempts to parse other datatypes in the list. This meant that when calling `cuttlefish_generator:map/2`, if something was already coerced to a valid datatype, it might fail to parse as the extended type and result in the nested configuration failing.

The main refactors are:

* 16a34ed : Broke `cuttlefish_generator:apply_translations()` up into smaller, more digestible functions with fewer responsibilities.
* 71f063c : Caught exceptions resulting from parsing standard datatypes such that they will not completely abort the process.
* cc78e53 : Added more guards to `cuttlefish_datatypes:from_string()` and `to_string()` that caused things like `list_to_atom(36000)` (as in the example in basho/riak#590).
* 039ca0a : Refactored `cuttlefish_generator:transform_type()` so that the functions it calls are not mutually recursive. The control flow was extracted out into a monadic combinator `foldm_either`, while the nested calls simply return `{ok, Value}` or `{error, Reason}`.
* df4c280 : Replaced all manual formatting of varialbes now that `cuttlefish_variable:format/1` exists. Found and fixed a resulting bug in `cuttlefish_escript:describe/2`.
This is so much cleaner, I'm just trying to convince myself that the logic is unchanged.  I take we don't actually need to look for `NewValue` in `PossibileValues`? Instead `cuttlefish_datatypes:from_string` would throw an exception?