Disable explicit nulls for JSON serializer

Describe your suggested feature

https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/json.md#explicit-nulls

https://github.com/tachiyomiorg/tachiyomi/blob/3760b310df8701f929d4ca4acbe7facfa97a2220/app/src/main/java/eu/kanade/tachiyomi/AppModule.kt#L80

- Json { ignoreUnknownKeys = true }
+ Json { ignoreUnknownKeys = true; explicitNulls = false }

Disabling explicit nulls enables people to write field: String? instead of field: String? = null when creating DTO classes for extensions (without creating another instance of Json). Having to write the default null is kinda unnecessary in my opinion since people rarely create instances of those manually.

This can avoid unnecessary errors when people forget to write the default null. These cases can be hard to test because:

• Tested manga list pages or manga details might happen to contain all those fields. The specific entry that omitted these fields (that the extension developer has seen when testing the API) might be un-tested in the app.
• Some websites have different behavior (either supply null or omit field) for the same model across different API endpoints, or even different entries. This might fool people into writing String? confidently on seeing the API returning "field": null for one specific response.

However people should not depend on this change until the next extension-lib update.

Other details

No response

Acknowledgements

• I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
• I have written a short but informative title.
• If this is an issue with an extension, I should be opening an issue in the extensions repository.
• I have updated the app to version 0.13.6.
• I will fill out all of the requested information in this form.

[arkon]

It’s generally fine to only support the latest stable version (with a bit of delay so people can update first), but the relevant changes also need to be communicated to the main fork devs to ensure they also have stable releases too.

[stevenyomi]

My consideration is that relying on the latest stable release might break compability with older working versions or other forks. It’s safest to bind the change with a new lib version so that all versions that implement the new lib can work with extensions flawlessly.