Separate runtime configuration from custom implicit definition in `Api` object

[lihaoyi]

Currently, if you define a new upickle.Api with e.g. different tagName or objectTypeKeyReadMap, you immediately lose the ability to use the upickle.default.ReadWriters defined by other people. This doesn't make sense, since by overriding those things you just want a custom runtime config and often don't want incompatible types at all

That is a consequence of us tying both custom-readwriters and runtime-configuration to the same upickle.foo object. The former needs to be there for implicit resolution of custom readwriters to work without imports (one of the goals of com-lihaoyi), while the latter is not really necessary.

in theory we could break them apart into two separate things that people can define and configure, or if we gave up on the "works without imports" thing we could just have a single object for runtime configuration and the implicits can live anywhere (but then you need to be careful with imports if you want to override something)

we could also have some kind of way of defining a new upickle.foo that lets you define runtime config but uses existing types e.g. upickle.default.{Reader,Writer,ReadWriter}. That could give us a new option to share the types but with a custom runtime config

[shanielh]

I just got this issue where I wanted to keep compatibility with other serializer that serializes nested object types as Something$Inner, so I override the method objectTypeKeyReadMap to replace . with $, but it didn't help, is this related to this issue?