Separate OPS framework from built-in operations

I know exactly how we can achieve a separation of concerns without burdening downstream consumers too much!
1. Create (again) `scijava-ops` with the core OPS framework.
- No dependencies on image-specific things (e.g., `imagej-common` or `imglib2`) of course.
- Remove the image-specific built-in op signatures from the `OpService` interface.
- Put the code generation layer and arithmetic operations, expression parser, etc., which are not specific to images, all in the `scijava-ops` component.
2. Keep `imagej-ops` as the place for all the image processing goodies.
- Provide a subinterface called `ImageOpService` which extends `OpService` and adds all the built-ins we want to have.
- Narrow the return type of the `ImageJ` gateway's `op()` method (in the `net.imagej:imagej` component) to return an `ImageOpService` instead of just an `OpService`. So anyone using an ImageJ gateway will have access to these image processing routines.

In this way, we will have the powerful SciJava OPS framework available to the world, including an awesome, extensible expression parser and evaluator. And the ImageJ OPS project as the flagship image processing routines built on top of it!