Held map rendering is unnecessarily slow in oceans (and may be slightly wrong)

When rendering held maps, to calculate the depth of water the current implementation uses the surface heightmap then linearly steps down the y axis until it finds a non-water block. Instead the ocean floor heightmap could be used and this would instead make calculating ocean depth take as long as reading 2 heightmap values and subtracting them and doesn't involve reading potentially 10s of blocks' blockstates.

Given the current implementation checks for fluidstate being empty and the ocean floor heightmap checks for solid blocks this would technically change the calculated depth slightly in some very specific edge cases (such as where there is air below the water), however; this is likely a bug in the current implementation as the depth logically makes sense to be the distance to the ocean floor, which the heightmap correctly stores.

This would result in significantly improved performance when updating maps with large oceans visible, with only a small change in behaviour in some edge cases that shouldn’t be able to happen in normal scenarios.

For an additional performance gain without any change to behaviour, instead of using copyHighestCountFirst and then getFirst (which does an unnecessary sort of the multiset) to get the colour to use for a pixel, instead you can just iterate through the entries and do a linear search for the highest count (you can also just return early out of this if any entry has more than half the total area of the blocks the pixel takes up).