Improved Game Data API integration tests

[danjagnow]

Improved all integration tests for the Game Data API by using the test utilities for deep comparison. Also updated model types that were discovered to have issues as a result of these improvements. These are breaking changes, so I'm also updating the version.json to bump the major version.

• Added a new AssetWithoutFileDataId class and updated the Assets property of CreatureDisplayMedia to use it since the non-nullable FileDataId does not appear to be returned with for this type.
• Fixed guild crest model types. Added a Colors property to GuildCrestComponentsIndex with a new GuildCrestColors model type to support it. Updated GuildCrestBorderMedia and GuildCrestEmblemMedia to use AssetWithoutFileDataId instead of Asset for their Assets properties.
• Added a PurchaseQuantity property to the Item model class.
• Updated JournalMedia to use AssetWithoutFileDataId instead of Asset for the Assets property.
• Fixed the Mount model type. Added a Requirements property with a new MountRequirements model type to support it.
• Fixed mythic raid leaderboard model types. Replaced the Zone property of the MythicRaidLeaderBoard model class with a JournalInstance property.
• Fixed pet model types. Added a missing Media property to Pet with a new PetMediaReference model type to support it.
• Fixed quest model types. Added a missing MaxCharacterLevel property to QuestRequirements. Removed the RecommendedMinimumLevel and RecommendedMaximumLevel properties from Quest.

Fixed RequestResultAssertions serialization options to use the same converters used by WarcraftClient for consistency. This is important to ensure that TimeSpan and DateTimeOffset properties round-trip properly.

[willwolfram18]

Glad to see the deep object comparisons are helping to improve the test coverage and making sure the models align with Blizzard's APIs!

[willwolfram18]

I'm thinking maybe we should make the FileDataId property on the original Asset class a nullable, i.e. long? FileDataId { get; init; }. Then it reduces the maintenance effort if an asset has more fields added that are shared between both models. What are your thoughts?

[danjagnow]

I'm thinking maybe we should make the FileDataId property on the original Asset class a nullable, i.e. long? FileDataId { get; init; }. Then it reduces the maintenance effort if an asset has more fields added that are shared between both models. What are your thoughts?

Yes, I'm of divided mind about that. It would reduce the number of types and avoid awkward type names with Without in the name. On the other hand, we would sometimes be returning objects with properties that can (for their usage in that particular method) never have a non-null value. I'm not really happy with either scenario. If you'd like to tip the scales one way or another, go for it.

[danjagnow]

I'll merge this as-is for now, but I'm open to reducing the number of nearly-identical types at the cost of some phantom properties that can only be populated in some contexts.