Fields can now easier support different data types in their underlying object.
These datatypes can be normalized to a single datatype using a normalization
transformer. The normalized value can then be transformed to the user's
representation with the value transformer (better name required?).
When reading the last bit of a property path mapped to a missing array index, the method would initialize the value to an empty array. This makes sense for cases where readPropertyPath would again be called recursively, but not when the value would be immediately returned (null would be preferable in that case).
For example, we have an object with a property called "options" that's an array of arbitrary key/value pairs. That "options" property (and getOptions()) maps directly to a FieldGroup within the Form for this object. That FieldGroup contains multiple TextFields for a few expected keys in the array. As-is, if those keys were not defined, the default data set for those TextFields could end up being "Array" (string representation of an empty array). If readPropertyPath instead returns null for this case, the default data would be transformed into an empty string.
Internally, ChoiceField expects both choices and preferred_choices to be a simple array, so I replaced incomplete bits of code that attempted to not modify a possible ArrayObject and instead added type checks in the configure() method (with unit tests for expected exceptions).
Property paths such as fields[group].fields[innerGroup].data were not being resolved correctly, since the second iteration of addError() (based on "group") would attempt to call get('fields') instead of get('innerGroup'). Solution is to remember to bump the propertyPath forward if we're at the fields property
