UE5.4 support, struct names, binrw

[scottanderson]

• Complete rewrite of model structs using binrw, with ~90% of types completely derived.
• Struct names are based on the corresponding Unreal Engine types.
• Support for Palworld save files through dedicated wrapper types.
• Fixes Palworld test are slow #56
• Fixes Unable to read save file for Medieval Dynasty #103
• Fixes Improve the separation of Property tags from property values #114
• Fixes [UE5.4] Property tag serialization support #134
• Bump package version to 0.11.0

Incomplete

• Type hints are not implemented. When type information is unavailable, FStructProperty::Custom will attempt to parse the property, and in the event that parsing fails, FStructProperty::Unknown will be used as a generic fallback. This type is distinct from FProperty::Unknown, because a UE4.5 FStructProperty::Unknown has its own type metadata and struct-guid.

[localcc]

Regarding the hints, I will look if the binrw crate can be trivially modified (potentially upstreamed) for access of the property stack

[localcc]

should chrono be an optional feature enabled by default?

[scottanderson]

Good idea, I will try it. I think chrono is only used for serde -> Display/FromStr -> chrono, so it might make sense to tie it to the serde feature.

[localcc]

what's the reason for those being commented out?

[scottanderson]

I think the comments are correct from my read of the code, but I have not verified them because the existing test fixtures don't have examples of these.

[scottanderson]

these comments can be removed, FTextHistoryNone handles that now.

Suggested change

	// #[brw(magic = -1i8)]
	// #[br(pre_assert(!format.culture_invariant_stability))]
	// Empty(),
	#[brw(magic = -1i8)]
	// #[br(pre_assert(format.culture_invariant_stability))]
	#[brw(magic = -1i8)]

[scottanderson]

I would prefer to leave FStructProperty derived, because it makes the code substantially easier to read.

I think it should be possible to move the variants that need custom handling into their own struct, and leave the enum itself as derived.

[localcc]

that seems like it would make matching on the fstructproperty values harder for users, is there a way to inline it with binrw?

[scottanderson]

This would not change the shape of FStructProperty.

With binrw, if a variant contains something that can't be derived, you can move just that part into a named type that manually implements the binrw traits, while keeping the parent enum derived.

Instead of:

enum FStructProperty {
    Variant(
        /* inner value that requires custom BinRead/BinWrite logic */
    ),
}

// FStructProperty manually implements BinRead/BinWrite

you can do:

#[binrw]
enum FStructProperty {
    Variant(InnerType),
}

struct InnerType {
    /* fields that require custom BinRead/BinWrite logic */
}

// InnerType manually implements BinRead/BinWrite

The public shape of FStructProperty is still the same kind of enum, so matching on it is unchanged in practice. The difference is just that the custom serialization logic is isolated to the part that actually needs it, rather than manually reimplementing the entire enum's serialization.