Fix small bug in samplePerlin

[xpple]

I have noticed a small bug in samplePerlin that sometimes causes a mismatch between Cubiomes' samplePerlin and Minecraft's ImprovedNoise#noise. I also renamed the ymin parameter to ymax because it serves as a maximum, not a minimum.

Here is a concrete example where the values disagree:

C:

PerlinNoise pn = {
    .d = {...},
    .a = 221.39371730024712,
    .b = 239.47976838647307,
    .c = 131.18609371637856,
};
printf("sample: %.20f\n", samplePerlin(&pn, -1172.05555, -5.34696875, -1005.230125, 4.277575000000001, -5.34696875)); // -4.98987353315497461637

Java:

Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
Unsafe unsafe = (Unsafe) f.get(null);

ImprovedNoise improvedNoise = (ImprovedNoise) unsafe.allocateInstance(ImprovedNoise.class);
Field p = ImprovedNoise.class.getDeclaredField("p");
unsafe.putObject(improvedNoise, unsafe.objectFieldOffset(p), new byte[]{...});
Field xo = ImprovedNoise.class.getDeclaredField("xo");
unsafe.putDouble(improvedNoise, unsafe.objectFieldOffset(xo), 221.39371730024712);
Field yo = ImprovedNoise.class.getDeclaredField("yo");
unsafe.putDouble(improvedNoise, unsafe.objectFieldOffset(yo), 239.47976838647307);
Field zo = ImprovedNoise.class.getDeclaredField("zo");
unsafe.putDouble(improvedNoise, unsafe.objectFieldOffset(zo), 131.18609371637856);
System.out.printf("sample: %.20f%n", improvedNoise.noise(-1172.05555, -5.34696875, -1005.230125, 4.277575000000001, -5.34696875)); // -0.07860539409676331000

The used array:

{-23, -27, 69, -116, -38, 126, -117, -5, 84, 111, -33, -115, -75, 34, -79, 48, 90, -47, -85, -12, 51, 70, -3, -77, -88, 125, 108, 15, -96, 13, -39, -100, 24, -122, 50, -37, -20, 88, 86, -120, 119, 52, -99, -69, -81, 68, -13, -58, 64, -80, -62, 122, -32, 106, 92, -49, 46, -93, -128, 1, 4, 74, 78, -90, 10, -1, 58, -11, -44, -19, -36, 85, 97, -43, 117, 95, -52, 47, -51, -68, -21, 73, -91, 8, -104, -41, 81, 99, 107, 61, 14, -24, -94, -84, 43, 0, -28, 71, -112, 56, 109, 100, -97, -108, 94, 124, -9, 7, -118, 37, -74, 36, 44, 72, -66, -95, 65, 17, -92, -86, -25, -30, 35, -109, 98, -82, -78, -15, 39, -16, -110, 67, 57, 9, 49, 113, 12, -89, -72, 63, -124, 75, 32, 29, -106, 93, -50, 6, 118, -48, -70, 27, 5, 80, -121, -103, 62, -102, -71, -8, -87, -56, -61, 87, 91, -119, -6, -45, 77, -123, 96, -114, -67, -127, 2, 89, 60, 121, -18, -34, 28, -111, 101, 76, 105, -42, 116, -4, -126, 112, -22, 18, 66, -31, 103, 53, -65, 104, 54, 38, -2, 40, 21, 102, 123, -53, 16, 25, -54, 83, 41, 55, 45, 59, -29, 79, -101, -17, -113, -73, -105, 20, -98, -76, -46, 127, -40, -14, -35, 42, 120, -7, 31, 33, -107, 22, -83, -125, 23, 26, 11, -10, 19, 30, 3, -57, -26, -63, 82, -60, 110, 115, -64, -55, 114, -59}

For the C code, append the first element of the array to the array.

With the fix in place, the same values are returned.

I noticed this issue when implementing base_3d_noise sampling. For example, the overworld uses the following noise:

BlendedNoise.createUnseeded(0.25, 0.125, 80.0, 160.0, 8.0).withNewRandom(randomState.random.fromHashOf(ResourceLocation.withDefaultNamespace("terrain")));

where randomState is an instance of net.minecraft.world.level.levelgen.RandomState. Note that for this specific example, one should use Cubiomes' octaveInit but with a Xoroshiro random. The above example values come from testing this noise.