Instruct fury to discard classInfo in the serialised data during deserialisation

### Feature Request

Scenario is specific to fury data migration.

We have serialised data in the db which is serialised without registering few classes, now we want to register the classes. This means, in the process we can encounter below two new scenarios :

- Data serialised by fury instance with class registration --> deserialised by fury instance without class registration -- **THIS DOES NOT WORK**

- Data serialised by fury instance without class registration --> deserialised by fury instance with class registration

Just wondering, is there a way to instruct Fury to disregard the classInfo in the serialised data during the deserialisation process?

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

As the serialised data contains classInfo, during serialisation fury seems to be expecting the class with same package structure or corresponding classes in registered with same classId to be deserialised. Making it difficult to refactor the data object in the migration.

### Describe the solution you'd like

Feature or flag that instructs the fury deserialiser instance not to consider the classInfo in the serialised data. Or any other solutions to get rid of class registration would be very helpful.

### Describe alternatives you've considered

_No response_

### Additional context

Code snippet to reproduce the issue locally.

```
import io.fury.Fury;
import io.fury.ThreadLocalFury;
import io.fury.ThreadSafeFury;
import io.fury.config.CompatibleMode;
import io.fury.config.Language;

public class FuryProblem {

public static void main(String... args) {
Wrapper wrapper = new Wrapper();
ComposedObject composedObject = new ComposedObject();
composedObject.setEnabled(true);
wrapper.setComposedObject(composedObject);
byte[] srcBytes = furyWithRegistration.serializeJavaObject(wrapper);
Wrapper resultWrapper = furyWithoutRegistration.deserializeJavaObject(srcBytes, Wrapper.class);
assert composedObject.getEnabled() == resultWrapper.getComposedObject().getEnabled();
}

public static ThreadSafeFury furyWithRegistration =
new ThreadLocalFury(
classLoader -> {
Fury f =
Fury.builder()
.withLanguage(Language.JAVA)
.withClassLoader(classLoader)
.registerGuavaTypes(false)
.withCompatibleMode(CompatibleMode.COMPATIBLE)
.requireClassRegistration(false)
.build();

f.register(Wrapper.class);
f.register(ComposedObject.class);
return f;
});

public static ThreadSafeFury furyWithoutRegistration =
new ThreadLocalFury(
classLoader -> Fury.builder()
.withLanguage(Language.JAVA)
.withClassLoader(classLoader)
.registerGuavaTypes(false)
.withCompatibleMode(CompatibleMode.COMPATIBLE)
.requireClassRegistration(false)
.build());

static class Wrapper {
ComposedObject composedObject;

public ComposedObject getComposedObject() {
return composedObject;
}

public void setComposedObject(ComposedObject composedObject) {
this.composedObject = composedObject;
}
}
static class ComposedObject {
Boolean enabled;

public void setEnabled(Boolean enabled) {
this.enabled = enabled;
}

public Boolean getEnabled() {
return enabled;
}
}

}
```

Start with the Java reproduction in the issue and inspect how the two ThreadLocalFury instances differ in registration and CompatibleMode configuration. Determine the intended deserialization behavior for registered and unregistered data, then define completion as a documented, tested way to handle this migration scenario or a clear explanation of its limitations.

Written by the indexing model from the issue text.