Change serialization strategy

[yuanchen233]

Using Kotlinx json serializer instead of Jakson wrapper.
This avoid converting incoming http messages into Jackson TreeNode before using core Json serializer.
Error handling in Jackson TreeNode were redundant, since kotlinx.serialization is eventually used.

Main changes:

• For all ApplicationServiceRequest endpoints, we treat incoming request as String and use carp.core json serializer to decode and build the request object.
• For all responses with carp.core domain models, we use core serializers to encode them into json string.
• For all Snapshot data saved in the database through core repository, core serialization is used to create the snapshot, but ObjectMapper.readTree is still used to create Jsonb values.
• Service layer usage of ObjectMapper is switched to Json

Reasons/Advantages:

• Carp core uses kotlinx.serialization, it's hard to maintain/keep track of which method to use.
• Jackson is Java first, it's creating annoying issues on how it handles Kotlin objects.
• Jackson rely on Reflection and serialize everything even if it does not know the type. While Kotlinx generate serializers at compile time, this ensures type safety, and also faster at runtime.

Other notes and TODOs:

• A serialization Json Bean is created for spring to autowire in some service classes, since current testing library need it to mock the value. We should consider to use this Bean for all occurrence, or import the object. (we are not changing the state of this serializer object, so I went with import object approach in the first place).
• Not all webservices domain models are using kotlinx, since they they are inherited from old java project. Serialization for them requires more testing, especially when saving 'Datastream' to the database.
• Account module is updated, since it also communicate with `Keycloak so more thoughts are needed here.
• Spring support kotlinx.serialization now, but it requires no Jackson configuration in classpath, consider working towards this.

[davidscavnicky]

very nice - @RequestBody httpMessage: String, will accept .json content as string
I understand now why you're making thin layer of WS regarding to serializers;

[davidscavnicky]

this is to be merged, since I want to follow up on unit tests. unsure if @NGrech wants to review this or the talk we had about this change was sufficient