SUBMISSION-87: Simplify proxy handling to better match legacy.

[DavidLFielding]

This PR backs off some of the changes I made in an attempt to separate proxy information from creator(submitter) information. The issue I had was that the Creator object initially stores the submitter's authoritative information, but Creator may later be updated by the submitter (with proxy permissions) by entering an unverified name and email via the Verify User page. These values simply overwrite submitter_name and submitter_email, which live on in Creator. Trying to break the Proxy concept out from Creator became impossible without something like event sourcing to fill in the deficiencies of the legacy database. The technical debt from legacy lives on for another day!

This PR works in terms of mapping the Creator fields (user_id, name, email) to the submitter fields in the legacy DB (submitter_id, submitter_name, submitter_email). The important thing to remember is that Creator may not represent the Creator of the submission in its entirety. The submitter_id it preserved. The submitter_name and submitter_email may be that of the proxied entity (not submitter_id) when a submitter is proxying for someone else. The creator object is closer to creator and contact with submitter identity(user_id) plus contact information (name, email), where only the user_id is immutable and the name/email may be updated by the submitter.

A few more things to clean up...remove owner (currently useless - identical to creator, to_submission sets both owner and creator to submitter User.