Add support for individual meta keys

This PR is a work in progress and aims to resolve #14.

## Overview

This update adds an option `$serialize_data` to `Fieldmanager_Field` to specify if that element should store its data serialized (the default) or unserialized (that is, using individual meta keys). This can be applied to a single repeating field, where the field is stored with duplicate keys, or to a group where each child gets its own key. In the case of a group, the field is prefixed with the group's name and an underscore. This update adds another option `$add_to_prefix` to `Fieldmanager_Group` allowing you the choice of whether or not to add that group's name to the prefix (`true` by default), which means you can completely separate your data structure from its presentation.

Groups can be nested any number of levels deep, and Fieldmanager will walk the nest until it finds either a group with `$serialize_data = true` or it finds a field. In other words, you can have a field nested within three groups, and still that field can have its own key. Again, you can choose individually which group's name will be prepended to the meta key. You can also mix-and-match depths, which is to say that you can have group with four children: three fields and another group, where the subgroup has two fields. You can set it such that the three top-level fields get their own keys, and the subgroup gets its own key with its children serialized, _or_ you can set it such the subgroup's fields each have their own keys too (making it so that all five fields have their own keys). While this may seem like a ridiculous edge case, it's entirely likely that you would want a group to work this if it has a tabbed group within it (see example 5 below).

The main area where this doesn't work is where a field's ancestor has a limit != 1. The only way to support such a structure would be to save to meta keys like `group_0_field`, `group_1_field`, etc., which would not be sustainable and it would be difficult and inefficient to work with in code. In every situation where an ancestor's limit != 1, it's much better to use serialized data.

Lastly, the submenu context does not support this at this time. I don't see the use case for it, but could be convinced otherwise.

## TODOS

* [x] repeating field where each iteration has its own key
* [x] groups where each child field has its own key (key name is {group}_{field})
* [x] groups where each child field has its own key without the group prefix
* [x] nth-level superfluous group which should be ignored in key prefixing
* [x] group within a group ... within a group where the fields to have their own keys
* [x] tabbed group where the fields have their own keys
* [x] group with one or more fields plus one or more groups
* [x] Add to all contexts (except submenu)
* [x] Add unit tests for sortable field using its own key
* [x] Error handling: incorrectly register a field with separate keys within a repeating group
* [x] Error handling: set `'serialize_data' => false` AND `'index' => true`
* [x] Error handling: register two fields using unserialized meta (at different depths or maybe in different FM fields) with the same name


## Examples

1. Repeating field where each iteration has its own key:
	```php
	$fm = new Fieldmanager_Textfield( array(
		'name'           => 'repeating_text_field',
		'limit'          => 0,
		'serialize_data' => false,
	) );
	$fm->add_meta_box( 'Repeating Standalone Text Field', 'post' );
	```

2. Groups where each child field has its own key (key name is {group}_{field}):
	```php
	$fm = new Fieldmanager_Group( array(
		'name'           => 'meta_fields',
		'serialize_data' => false,
		'children'       => array(
			'text'     => new Fieldmanager_Textfield( 'Text Field' ),
			'textarea' => new Fieldmanager_TextArea( 'TextArea' ),
			'checkbox' => new Fieldmanager_Checkbox( 'Checkbox' ),
		)
	) );
	$fm->add_meta_box( 'Single-Level Group', 'post' );
	```

3. Groups where each child field has its own key without the group prefix:
	```php
	$fm = new Fieldmanager_Group( array(
		'name'           => 'meta_fields',
		'serialize_data' => false,
		'add_to_prefix'  => false,
		'children'       => array(
			'text'     => new Fieldmanager_Textfield( 'Text Field' ),
			'textarea' => new Fieldmanager_TextArea( 'TextArea' ),
			'checkbox' => new Fieldmanager_Checkbox( 'Checkbox' ),
		)
	) );
	$fm->add_meta_box( 'Single-Level Group', 'post' );
	```

4. Tabbed group where the fields have their own keys:
	```php
	$fm = new Fieldmanager_Group( array(
		'name'           => 'tabbed_meta_fields',
		'tabbed'         => true,
		'serialize_data' => false,
		'add_to_prefix'  => false,
		'children'       => array(
			'tab-1' => new Fieldmanager_Group( array(
				'label'          => 'Tab One',
				'serialize_data' => false,
				'add_to_prefix'  => false,
				'children'       => array(
					'text' => new Fieldmanager_Textfield( 'Text Field' ),
				)
			) ),
			'tab-2' => new Fieldmanager_Group( array(
				'label'          => 'Tab Two',
				'serialize_data' => false,
				'add_to_prefix'  => false,
				'children'       => array(
					'textarea' => new Fieldmanager_TextArea( 'TextArea' ),
					'media'    => new Fieldmanager_Media( 'Media File' ),
				)
			) ),
		)
	) );
	$fm->add_meta_box( 'Tabbed Group', 'post' );
	```

5. Tabbed group within a group, where all fields have their own keys. This will save data to four meta keys: `title`, `text`, `textarea`, and `media`. All of the groups are ignored except in presentation.
	```php
	$fm = new Fieldmanager_Group( array(
		'name'           => 'base_group',
		'serialize_data' => false,
		'add_to_prefix'  => false,
		'children'       => array(
			'title' => new Fieldmanager_TextField( 'Title' ),
			'tabs' => new Fieldmanager_Group( array(
				'tabbed'         => true,
				'serialize_data' => false,
				'add_to_prefix'  => false,
				'children'       => array(
					'tab-1' => new Fieldmanager_Group( array(
						'label'          => 'Tab One',
						'serialize_data' => false,
						'add_to_prefix'  => false,
						'children'       => array(
							'text' => new Fieldmanager_Textfield( 'Text Field' ),
						)
					) ),
					'tab-2' => new Fieldmanager_Group( array(
						'label'          => 'Tab Two',
						'serialize_data' => false,
						'add_to_prefix'  => false,
						'children'       => array(
							'textarea' => new Fieldmanager_TextArea( 'TextArea' ),
							'media'    => new Fieldmanager_Media( 'Media File' ),
						)
					) ),
				)
			) )
		)
	) );
	$fm->add_meta_box( 'Tabbed Subgroup', 'post' );
	```

6. A group with a child field and a subgroup, each with their own keys, where the subgroup does use serialized data. Here, the stored meta keys will be `'meta_fields_text'` and `'meta_fields_subgroup'`.
	```php
	$fm = new Fieldmanager_Group( array(
		'name'           => 'meta_fields',
		'serialize_data' => false,
		'children'       => array(
			'text'     => new Fieldmanager_Textfield( 'Text Field' ),
			'subgroup' => new Fieldmanager_Group( array(
				'children'       => array(
					'text'     => new Fieldmanager_Textfield( 'Text Field' ),
					'textarea' => new Fieldmanager_TextArea( 'TextArea' ),
					'checkbox' => new Fieldmanager_Checkbox( 'Checkbox' ),
				),
			) ),
		),
	) );
	$fm->add_meta_box( 'Multi-Level Groups', 'post' );
	```
Hypothetically you could, but there's no point in doing so. `index` stores a field's value in duplicate outside of the serialized array so that that field can be used in meta queries. However, the serialized array is still the canonical home for that data. When I was building this, I was thinking that `index` forced you to use the field's `name`, which isn't the case -- you can set any arbitrary meta key for it. I'm inclined to leave the exception in place, since it is pointless to use both on the same field and using both increases the likelihood of naming collisions. If you can think of a business case for using both in a field, let me know and I'll be happy to reconsider.