Solve class definition race conditions

[Moulberry]

My mod uses the vanilla ModelBlockRenderer to tesselate blocks on the main render thread. Unfortunately, there exists 2 race conditions in VertexSerializerFactory which results in LinkageErrors being thrown due to duplicate class definition. See below for example stacktrace.

This PR does 2 things:

1. Calls createSerializer after acquiring the write lock
2. After acquiring the write lock, does an additional check to see if cache was already written to. As explained, this secondary check is necessary due to 'find' using a non-exclusive lock

Example crash without this fix:

java.lang.LinkageError: loader net.fabricmc.loader.impl.launch.knot.KnotClassLoader @731a74c attempted duplicate class definition for me.jellysquid.mods.sodium.client.render.vertex.serializers.generated.VertexSerializer$Impl$0005$0008. (me.jellysquid.mods.sodium.client.render.vertex.serializers.generated.VertexSerializer$Impl$0005$0008 is in unnamed module of loader net.fabricmc.loader.impl.launch.knot.KnotClassLoader @731a74c, parent loader net.fabricmc.loader.impl.launch.knot.KnotClassLoader$DynamicURLClassLoader @4b4523f8)
	at java.base/java.lang.ClassLoader.defineClass0(Native Method)
	at java.base/java.lang.System$2.defineClass(System.java:2307)
	at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2439)
	at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2416)
	at java.base/java.lang.invoke.MethodHandles$Lookup.defineClass(MethodHandles.java:1843)
	at me.jellysquid.mods.sodium.client.render.vertex.serializers.generated.VertexSerializerFactory.define(VertexSerializerFactory.java:225)
	at me.jellysquid.mods.sodium.client.render.vertex.serializers.VertexSerializerRegistryImpl.createSerializer(VertexSerializerRegistryImpl.java:81)
	at me.jellysquid.mods.sodium.client.render.vertex.serializers.VertexSerializerRegistryImpl.create(VertexSerializerRegistryImpl.java:50)
	at me.jellysquid.mods.sodium.client.render.vertex.serializers.VertexSerializerRegistryImpl.get(VertexSerializerRegistryImpl.java:43)
	at com.mojang.blaze3d.vertex.BufferBuilder.copySlow(BufferBuilder.java:582)
	at com.mojang.blaze3d.vertex.BufferBuilder.push(BufferBuilder.java:572)
	at me.jellysquid.mods.sodium.client.render.immediate.model.BakedModelEncoder.writeQuadVertices(BakedModelEncoder.java:95)
	at com.mojang.blaze3d.vertex.BufferBuilder.putBulkData(BufferBuilder.java:1563)
	at net.minecraft.client.renderer.block.ModelBlockRenderer.putQuadData(ModelBlockRenderer.java:144)
	at net.minecraft.client.renderer.block.ModelBlockRenderer.renderModelFaceAO(ModelBlockRenderer.java:120)
	at net.minecraft.client.renderer.block.ModelBlockRenderer.tesselateWithAO(ModelBlockRenderer.java:77)

[jellysquid3]

Ouch! That's a terrible bug on our part.

Maybe we should use a ConcurrentHashMap instead? I believe if two threads call ConcurrentHashMap.computeIfAbsent then only one thread will compute the value, and both threads will be returned that value. That would also ensure the registry doesn't stay locked for too long while defining a class.