fixed issues with unintentional value changes when using the built-in form

[craue]

This fixes issues with unintentional value changes when using the built-in form to manage settings.

When a new setting is added between rendering and submitting the form, values might be wrongly assigned to other settings. This happens because the settings used to be added as a collection whose fields are usually ordered by the settings' names. Now, if a setting is added in the database, the order of fields could change (depending on the new setting's name) but the submitted values are assigned to fields corresponding to the original order.

Additionally, values of settings not submitted by the form (i.e. not present in the request) used to be effectively set to null.

To illustrate both issues:

1. given settings (and values): name1 (value1), name2 (value2)
2. render the form
3. add new setting name11 (value11) into the database
4. submit the previously rendered form unchanged
5. persisted settings: name1 (value1), name11 (value2), name2 (null)

Now with these fixes, the last step would correctly be:

5. persisted settings: name1 (value1), name11 (value11), name2 (value2)

In order to fix these issues, form field names are now name-based (instead of previously index-based). Thus, form or template customizations need to be revised to reflect these changes.

[coveralls]

coverage: 100.0%. remained the same when pulling 090dae3760d962b5ac535c77570c327c36a66d2b on fix-form into 5bf3673fc116cab92b9943c88dc514e9ca8ad4ad on master.