Fix behavior of data entry for complex fields containing only one subfield

It is conceivable that a client will have a field in his schema which is complex and has only one subfield. The Web UI does not properly handle entry of values in this case.

For example, if a field in a schema is defined xSingleVal[]: Complex(sString) and the following elements are defined in a layout for it, upon creation or modification the entered values will be saved as null.

    <nuxeo-data-table role="widget" items="{{document.properties.sample:xSingleVal}}" orderable="true" editable="true">
      <nuxeo-data-table-column name="S String">
        <template>
          [[item.sString]]
        </template>
      </nuxeo-data-table-column>

      <nuxeo-data-table-form>
        <template>
          <nuxeo-input value="{{item.sString}}" label="S String" type="text"></nuxeo-input>
        </template>
      </nuxeo-data-table-form>
    </nuxeo-data-table>

There is a scenario which is similar to this which reveals the same issue. A client has a schema containing a complex multivalue field, but defines the layout to enter data into only one of the subfields, for example, the field is defined xThreeSubs[]: Complex(sLink,sDesc,sOriginalValue) and the layout contains the following:

    <nuxeo-data-table role="widget" items="{{document.properties.sample:xThreeSubs}}" orderable="true" editable="true">

      <nuxeo-data-table-column name="S Original Value">
        <template>
          [[item.sOriginalValue]]
        </template>
      </nuxeo-data-table-column>

      <nuxeo-data-table-form>
        <template>
          <nuxeo-input value="{{item.sOriginalValue}}" label="S Original Value" type="text"></nuxeo-input>
        </template>
      </nuxeo-data-table-form>
    </nuxeo-data-table>

One could argue that it's inadvisable to define a complex field with only one sub-field when a plain multi-valued field would be sufficient. A plain multi-valued string would work correctly in the first scenario. This argument can be countered with the fact that a schema with a complex field having only one sub-field is not an invalid schema, and there's an advantage in being able to define a schema with complex fields that can be expanded in the future.