Storage format: custom vs kotlinx serialization

[d-r-q]

Actual behavior: Eavs are serialized to trx log via custom serialization.

Quality for this serialization is unclear and it's more difficult to implement support of nested map attributes using custom serialization.

Consider switch to kotlinx.serialization/CBOR.

• Restore serialization test

Comparison matrix:

	custom	kotlinx
Dependencies	None	On stdlib
Multiplatform	Yes	Yes
Performance	???	Probably more performant
Memory footprint	???	Probably more effective
Support of Maps	Hard	Build-in
Requrements for stored data	No	Probably will require some changes in qbit data structures

kotlinx advantages:

• Probably will resolve Fix numbers storing durty hacks #114/Fix js numbers rtti workaround #132

[d-r-q]

There are some strange behavior of numbers on js - objects that at compile time has type Byte, at run time are Int. And due to this "feature" custom serialization doesn't. I suggest, that there're more such issues, so decide to migrate to kotlinx serialization and move this issue to mpp project

[d-r-q]

Look like there is no magic, and Kotlin serialization also cannot handle the problem. The problem is that in Eav have no meta information about value type and there is no sound way to determine value type by value itself. To mitigate the problem type meta information should be introduced in Eav someway, but Eavs, are actually used almost everywhere, so I decided to postpone the change to clean up stage, to ensure, that new version for sure works for multiplatform.