Speed time to move on from superpixel generation step

[bnmajor]

After we've requested superpixel generation we should:

1. Immediately make the initial labeling UI available. There will be no superpixels to label yet but users will be able to create/setup categories in the meantime.
   1. It would be good to also provide meaningful feedback of some kind to explain current state limitations/progress towards superpixel availability.
2. Once the first image has superpixels available, labeling should be enabled
   1. Meaningful feedback again
   2. Image selection should probably show all images but disable selecting those that are not yet available to make it more obvious how much progress has been made
3. If the user requests to begin training before the superpixel generation has completed we need to make sure that it is queued to start after that job is complete.
   1. We need to make sure that a queued job request is not lost/forgotten when the user leaves/refreshes the page, etc.

[manthey]

More for documentation than for action, we current generate superpixels in parallel by image but sequentially on tiles within an image. We then generate features in parallel by image. Investigating these steps, the superpixel generation is CPU bound (but if you have fewer images than cores, it isn't doing all it could). The feature generation is I/O bound. Neither had any measurable harm or benefit in using multiprocessing rather than multithreading.

There is a package called cuda-slic, but this doesn't support masks which we use to prevent tile boundary effects.

[bnmajor]

Completed in #116