Remove OpenCV as a dependency for qupath-core

[petebankhead]

Design issue

Describe the bug
qupath-core doesn't - and shouldn't have many dependencies.

However, it does currently have a dependency on OpenCV. This brings in JavaCPP and platform-dependent native libraries, in a way that potentially makes qupath-core much heavier that it would otherwise be.

Usage

There are really only two places where OpenCV is used in qupath-core:

• Image resizing
• Type adaptors for Gson

Required change

I think (hope) type adaptors can be shifted to qupath-core-processing without too much trouble.
Although since the change was introduced in 0f0229f the commit message hints that there was a reason to including it in qupath-core that might resurface in the future.

I expect that the main effort would go into reimplementing image resizing. Ideally, we'd do this without introducing any new dependency (including ImageJ) to retain full control over the code and not have it subject to change with dependency updates.

I expect that will be a very fiddly task, requiring some very good unit tests.

Additional context

Resizing is performed whenever tiles are requested, e.g.

qupath/qupath-core/src/main/java/qupath/lib/images/servers/AbstractTileableImageServer.java

Lines 436 to 442 in 48dfb82

	// Return the image, resizing if necessary
	BufferedImage imgResult = new BufferedImage(colorModel, raster, alphaPremultiplied, null);
	int currentWidth = imgResult.getWidth();
	int currentHeight = imgResult.getHeight();
	if (currentWidth != width || currentHeight != height) {
	imgResult = BufferedImageTools.resize(imgResult, width, height, allowSmoothInterpolation());
	}

In this case, it is almost always downsampling.

We need to support both a 'smooth' and a 'nearest neighbor' implementation, to handle intensity and labeled/binary images at least - although we might want to introduce more interpolation options.

See also qupath/2022-qupath-hackathon#2 (comment)

Significance

Having OpenCV as a dependency of qupath-core showed up when testing on a M1 Mac: it meant nothing would work until OpenCV had compatible binaries. It does now, but that flagged the issue of OpenCV being dragged into pretty much everything.

Removing it would mean that the core module - and therefore most serializable datastructures - depend upon only Java code. This could help in making it accessible elsewhere, e.g. from Python or R.