Use the Context's recommended threading mechanism

@bnorthan [writes](https://gitter.im/imagej/imagej-ops?at=5c91759a2f6ded0abb0ed5ca):
> I just noticed that some ops set the number of threads using `Runtime.getRuntime()` would it be better for every `Op` to use the threading service and get the number of threads available from that??
> For example [dilate](https://github.com/imagej/imagej-ops/blob/imagej-ops-0.43.2/src/main/java/net/imagej/ops/morphology/dilate/DefaultDilate.java#L128)

All ops should use the `ThreadService`—and especially _not_ use `Runtime.getRuntime().availableProcessors()`—when deciding how many threads to spawn. One challenge to this approach is that `ThreadService` does not currently have any sort of `recommendedThreadCount()` method. So for situations like `dilate` above, it is unclear how many threads to signify when delegating to the underlying algorithm implementation. Perhaps we should add such a method to the `ThreadService`. But ideally, every underlying algorithm implementation would accept an `ExecutorService` parameter for use in spawning threads, so that the `ThreadService`'s corresponding `ExecutorService` could be passed directly.

Start with the threading logic in src/main/java/net/imagej/ops/morphology/dilate/DefaultDilate.java and inspect the ThreadService API and the other ops that use Runtime.getRuntime().availableProcessors(). Determine the project-wide approach for obtaining thread counts or passing an ExecutorService, then verify that all affected ops use the Context's threading mechanism without directly querying Runtime.

Written by the indexing model from the issue text.