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(#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.