AttachmentType Registration Enhancements

[forgetmenot13579]

Register AttachmentTypes using the builder with consumer pattern.

Today, using the builder pattern creates a Builder<Object> by default, making both the persistent method and the initializer method largely useless, which is especially problematic as this is currently the only way to create an attachment with both persistence and a default value.

While this can be avoided by explicitly providing type parameters to the static AttachmentRegistry#builder method, type parameterizing methods is unintuitive and should be avoided as an API pattern whenever possible.

The solution implemented in this PR is the addition of the AttachmentRegistry#create(Identifier id, Consumer<Builder<A>>) method. This allows users to configure the (better type inferred) builder directly.

[modmuss50]

The motivation for this change is to avoid holding onto the mod ID in magic static strings as much as possible.

This does not seem like the solution to this problem, and barely changes anything as it doesnt solve it in every other place you create an identifier. Just create a static method that returns an identifier so you can do MyMod.id("path"). This is a none issue that this change doesnt solve.

[forgetmenot13579]

I disagree that it is a nonissue, but it is true that solving it here specifically does not make much of a difference when the problem persists across the rest of the ecosystem. I have removed that feature and updated the PR summary accordingly.

[Syst3ms]

Mostly nitpicks, this is a reasonable change. I think the entrypoint thing was well out of scope, though. This won't be too big of a hassle to merge into attachment sync.