Added the ability to set a custom stub cell value instead of np.nan

[freemansw1]

This should resolve (most of) #62. Rather than set the stub/non-tracked cells as np.nan, tobac.tracking.linking_trackpy now accepts stub_set_number as a parameter for the value of cell to set the stub/non-tracked cells to, with a default value of -1.

[deeplycloudy]

I tested this (after porting to v2.0-dev), and it resolves the float-coercion problem in #62.

By definition, the lists of segmentation IDs and feature IDs are separate, so I agree segmentation is a separate discussion.

Is "stub" a term in the public API, or a term internal to the implementation? For symmetry with other kwargs, I think I'd prefer something like cell_number_unassigned instead of stub_set_number. That mirrors cell_number_start.

[deeplycloudy]

Also, thinking about metadata: it would be good to capture the user's chosen stub/unassigned number as an attribute. I could propose how to do that for xarray, but not sure if iris supports such metadata.

I'm very interested in having the metadata. When working with a combined dataset (features, the feature mask, and cells) one would need to know which ID to ignore, and this function seems like the right place to add that metadata so it can be used appropriately downstream. While the user knows the ID when creating the dataset, that information is lost when those data are saved to an archive apart from the software.

[freemansw1]

"stub" is indeed used in the public API (see tobac.tracking.linking_trackpy), although it definitely shouldn't be as the language isn't intuitive. I'll switch to cell_number_unassigned as you suggest here.

The issue with metadata here is actually with pandas rather than iris, as in v1.x, the feature/tracking data comes out as a pandas DataFrame. Pandas has the DataFrame.attrs dict, but it is described as experimental. For now, I'm going to add the selected unassigned cell value there as cell_number_unassigned.

I (or someone else) will need to port this to v2.x, but I'm hesitant to make any ports until we get to v1.5.

[freemansw1]

I've moved this to the v1.3 milestone to match the issue (#62).

[freemansw1]

Per our discussion last week, waiting on #78 to be merged before merging this.

[freemansw1]

I've updated the formatting per #78

[w-k-jones]

Happy for this to be merged

[freemansw1]

Now that #89 has been merged, I need to update this PR to avoid the conflicts.

[freemansw1]

I've updated it to avoid the conflict and I will re-request a review to keep with good practices before merging.