Use TaskExecutor instead of doWork for long-running tasks

**General idea**: use napari threads + our wrapper (TaskExecutor) + service classes instead of custom multi-threading solutions.

**Problem**: training and prediction both rely on `doWork` and `startLongRunningTaskWithProgressBar`, which are methods of the view superclass.

**Solution sketch**: (this is for training, but same idea can be applied to prediction)
1. introduce model state `training_in_progress` + signal `training_in_progress_toggled`
2. upon user clicking 'start training' set `training_in_progress` to `True` in the model
3. `training_in_progress_toggled` signal will emit `True`, view listener will then display progress bar, service listener will spin up training + fs event handlers
4. Instead of handling progress changes in `progress tracker`, just track those variables directly in the model, then the view can listen for changes to them and update the progress dialog accordingly
5. When service is done training, sets `training_in_progress` to `False` in the model
6. `training_in_progress_toggled` signal will emit `False`, causing the view to hide the progress dialog.

**Cool side effects**:
- can actually test the behavior of the training progress bar without starting any long-running processes or going crazy with mocks
- helps to standardize multi-threading strategy for the repository
- gets rid of the `View` superclass, which I'm not a fan of b/c it requires metaclass configuration which is a deep topic with potential pitfalls
- we could easily track loss in model state, which would mean we could get rid of some code I wrote that I don't like bc it reads from the FS on the main thread (this is related to showing loss at the end of training)

**Not-so-cool side effects**:
- (already large) model classes will grow larger
- probably a sizable refactor