Disallow sources to access or delete their own submissions

[eaon]

Basic testing done, working as expected. Fixes #10.

It turns out the codebase already distinguished between file_id and file_name, both of which are randomly generated secrets.token_hex(32) values. This adapts the use of these variables, making file_id knowable by the source, and changes file_name to be used to access/delete a particular file.

Journalists create a signed map of file_id and file_name key/values, which they share. Any long-term journalist signature is verified by the server, adding the respective mappings as members to the file_token redis set. This then allows the server to tell sources what they're allowed to learn (file_id) when submitting anything, while journalists can infer what they need to learn (file_name) when they receive messages or want to reply to a source. In the case of the latter, sources have to be told what they needs to know (file_name) by journalists without supplying other details of the public/private file_id/file_name map.

Notes

1. I don't know if there was a significant reason for distinguishing between file_name for file-system names and file_id for database/remote access names, but as far as I can tell there is no need to hide on-disk file names from recipients. Happy to adapt if this is still something we want to continue to do.
2. The base branch for this PR is messages-as-attachments (i.e. Treat messages and metadata as attachments #8), as protocol symmetry is a key point of this change (even though it could be adapted to just not send replies as file uploads, i.e. the source would not need to learn file_name)

[eaon]

Closing this as it's overall more impractical than a public-key cryptography based approach (touched on in #10 (comment) although that exact line of thinking is also outdated) to solve this issue.