Goals:

1. I'd like more separation between the "pure logic", functions on/between the various data types, and the serialization logic

2. I hope we will eventually have a new derivation format that is more flexible Switch store derivations from using ATerm to using JSON or some other mainstream format #5481, and am using the JSON format to try out what that should look like. (Or maybe it will just be the JSON (for isomorphic CBOR) format, but not sure.)

#10760, for example, is directly about (2). But I think it would be also good to split out derivation-aterm.cc and derivation-json.cc at some point for (1) and (2).

Also, I think I made a mistake when I made content-address.hh declare a bunch of weird (de)serialization methods that are for the ATerm format, store path calculation, and other such things. The ones that are e.g. content addressing method enum <-> string for name of the variant are fine, because they are generally informative. But the more complicated ones that have all the : feel like a mistake to me, because they violate (1).

I think that putting all those in that header / as methods was a bit of an overeager deduplication on my part, and it would be better to keep that logic with the ATerm and store path logic (1). This is because the ATerm format and the store path calculation are conceptually totally separate things (except for the derivation format containing final, opaque store paths), and any sharing of calculations that they do is more incidental than that sharing deeply "meaning" anything.

Or, at the vary least, if the methods weren't duplicated, they should move to something like content-address-misc-serialization.hh so they would at not "polite"/"distract" all other users of content-address.hh, and just be used the serialization logic modules that actually needs them.