Mapping updates in response to certain mutations

[stuarteberg]

• When a supervoxel is split, the supervoxel must be added to the in-memory map, with a body of 0
• When a body is cleaved, the newly allocated body ID must be added as a SUPERVOXEL in the mapping, with a body of 0
• If we ever implement any "body renumber" feature(Explicit renumbering of body IDs #360), then DVID should also add the new body ID as a supervoxel ID in the mapping, with a body of 0.

Obviates #323
Related: #289, #297

While you're at it, if you could handle #267 (task 3), that would be great:

3. split-supervoxel messages could include the body ID

[DocSavage]

Fully fixed by commits d7ae3c9 and db19cbe. Because this slightly modifies what a "mapping" constitutes, i.e., the id-to-be-mapped is not always a supervoxel, the documentation for the /mapping endpoint has been changed to emphasize it:

GET <api URL>/node/<UUID>/<data name>/mapping[?queryopts]

	Returns JSON for mapped uint64 identifiers (labels). The mapping holds not only the
	unique IDs of supervoxels but also newly created IDs for renumbered & cleaved bodies
	that will never overlap with supervoxel IDs. 
	
	Expects JSON in GET body:

	[ label1, label2, label3, ...]

	Returns for each POSTed label the corresponding mapped label:

	[ 23, 0, 911, ...]

	The mapped label can be 0 in the following circumstances:
	* The label was a supervoxel ID that was split into two different unique IDs.
	* The label is used for a newly generated ID that will be a new renumbered label.
	* The label is used for a newly generated ID that will represent a cleaved body ID.

[stuarteberg]

@DocSavage Just to be clear: These changes affect not only the /mapping endpoint, but also the complete /mappings endpoint, yes?

[DocSavage]

@stuarteberg Yes. I'm pushing a change to the documentation for GET and POST /mappings as well to make clear the mapping keys aren't just supervoxel ids any more.