[Java] ClassResolver separates ClassIdAllocator

[LiangliangSui]

Is your feature request related to a problem? Please describe.

1. ClassId is allocated using ClassIdAllocator. The ClassId allocation task is separated from ClassResolver. ClassIdAllocator is referenced in ClassResolver to reduce the complexity of ClassResolver.
2. The interface is exposed to users through the Fury class. Users can obtain a ClassId through the interface instead of specifying it at will (specifying it at will may trigger an exception)

Additional context

Could you elabrate more the ClassIdAllocator?
I'm not sure how it handle such an situation: there are three libraries and one client of three libraries. Every libraries has some classes to register, but they can't assume the register order since they don't know which will be registered first, so they use specified class id for such registration. If the client has two versions, the first version use library1 and library2, and the second version use library1 and library3. Then the registered ids in library2 should be left here, those ids shouldn't be used by library3. Will the ClassIdAllocator handle such cases?

The purpose is to retain the ClassId registered in lib2.

Can we define such an interface such as allocateClassId(short beginClassId)?

This way the user can specify the starting position of the ClassId.

If the user does not specify beginClassId, Fury will take over the entire ClassId assignment.

That is, exposing two interfaces to users

Fury#allocateClassId(short beginClassId)
Fury#allocateClassId()

[LiangliangSui]

Hey @chaokunyang , we can discuss ClassIdAllocator related content here.