Rename repository methods to use store/fetch/update/remove

[karlhigley]

We talked about this change recently in a few different conversations, so I went ahead and put it together. These methods are basically CRUD, but the semantics of create/read/update/delete aren't quite right here. Since our domain objects aren't coupled to the underlying storage technologies, we can create an account with the normal Python constructor Account(email=...) without storing it anywhere and then decide where/how to store it. This should really come in handy with some of our upcoming data export work, because it will mean that we can create e.g. id mapping objects that are never stored in the database but instead written to files while maintaining an easy path for importing them into the database.

It also opens up a possibility for testing our platform code without the database, which is that we can use an InMemoryWhateverRepository class (potentially from this repo) that has all the same methods and does all the same things but just holds the objects in memory instead of storing them anywhere. In this repo, we can test that the Db/S3/InMemory implementations are interchangeable, and in poprox-platform we can then avoid having to create mocks for the Db/S3 repositories or stub their individual methods but still be able to test that the platform code works the way we expect without involving a database or S3.

[kluver]

Looking good. I think fetch and store match the semantics a lot better.

[kluver]

I'm working on resolving conflicts right now.