DefaultOverlaySerivce.getSelectionBounds miscalculates height and width

In [this method](https://github.com/imagej/imagej-common/blob/35c26c609f97ffd827cb62201e69dacf474849a3/src/main/java/net/imagej/display/DefaultOverlayService.java#L165) the selection bounds return object is given as a `new RealRect(xMin, yMin, xMax - xMin, yMax - yMin)` (see [constructor](https://github.com/scijava/scijava-common/blob/821f89fc53bd2f3ffe75c14cd35eb74d5b4e545e/src/main/java/org/scijava/util/RealRect.java#L56)). `xMin`/`xMax`/`yMin`/`yMax` are found by calling `realMin(dimension)` or `realMax(dimension)` on the `Data` object of the input `ImageDisplay`'s `DataView` or from the `ImageDisplay`'s bounds itself. For example, an image `image` of size 256/256, `xMin`/`yMin` will be 0 and `xMax`/`yMax` will be 255. This causes `image.width` and `image.height`, according to the above, to be 255, which is wrong, since it causes plugins like [this one](https://github.com/imagej/imagej-plugins-commands/blob/master/src/main/java/net/imagej/plugins/commands/correlate/SharpenDataValues.java) to not calculate the last column/row (see the driving for-loop [here](https://github.com/imagej/imagej-plugins-commands/blob/ba691ddab17bc6a6f304505b1704aa6435e23fbf/src/main/java/net/imagej/plugins/commands/neigh/Neighborhood3x3Operation.java#L159)).

Start in src/main/java/net/imagej/display/DefaultOverlayService.java at getSelectionBounds and read the linked RealRect constructor to confirm the coordinate semantics. Compare the result with the 256×256 example and the Neighborhood3x3Operation loop; done means the final row and column are included with width and height 256.

Written by the indexing model from the issue text.