Dynamic Primary Keys

[nullpilot]

This is the refactored version of #151, which addresses the hard-coded id primary key, and issues discussed in #6.

The first two commits are the same as before, with merge conflicts resolved. The rest are to implement list actions and address some of what was discussed in the linked issue, hoping to make this change a less rough around the edges. 😃

The default serialization method remains unchanged from the old PR, but the separator was changed to ":", and an example on how the serialization could be done with ETF instead, for cases where the former method may introduce ambiguity, was added to the docs.

For the list actions, I split the behavior as follows:

• Records with a single primary key use the same query as before and should work exactly the same, just with the key itself being pulled from the schema.

• List actions on records with a composite key use a dynamic query with an or_where([pk1: val1, pk2: val2, ...]) clause per record. I don't love this solution, but where: ^composite_key in ^values type of queries are not a thing (yet?), and I found no way to get around it with fragment/dynamic/field/type trickery.

Happy to hear your thoughts!

[aesmail]

Amazing work @nullpilot !

I feel like this feature deserves more than a "patch" version increment 😄

If you could just add tests for it, this would be merged as soon as all tests are passing 🙏🏼

[nullpilot]

I fixed the tests and added a few for the green path. Ideally I would like to improve error handling some, but it didn't do too much for that yet. Another change I considered but haven't added to this PR, is to make the default deserialization cast back to the schema type. It felt a bit too fickle, and Ecto handles it further down the pipeline anyway, probably with better error handling.