Create unified submission staging for ingestor and manual submissions

[abn]

This is the parent issue for implementing this into victims-web.

Requirement 1: Implement a new collection of the following structure:

{
'submitter': { 'name': 'victims-ingestor' },
'submittedon': NOW,
'source': URI,
'category': 'java',
'cves': ['CVE-1', 'CVE-2'],
'approval': {'date': DATE, 'status': REQUESTED },
'entry' : {} #to be populated once a scan is being done
'comment': "" #Can be used to add reason why it was declined
}

Requirement 2:

implement an admin view in the
victims-web that lists all submissions (i think there is one for user
submissions - you can reuse that or implement one of your own). This is
so that an admin can view the list of submissions filtered on
approval.status, default filter would be 'REQUESTED'. 

Probable status value could be ['APPROVED', 'PENDING_APPROVAL' ,'IN_DATABASE',
'DECLINED', 'REQUESTED', 'INVALID']. 

(informal requirements - feel free to improvise)
In this view, the admin should be able to 
        1. view details of a submission
        2. request the URI be downloaded, scanned and file hashes entry added
to 'entry' field in the collection (such that this dictionary can just
be added into victims.hashes if/when approved).
        3. Once a scan is done it can move to SCANNED status
        4. An admin can review the entry and move it to APPROVED/DECLINED
        5. If APPROVED the server can move the entry to the database and set
status to 'DATABASE'.

For 2, if the the status is 'DATABASE' or 'SCANNED' or 'DECLINED' - the
step can be skipped as an entry already exists somewhere.

[abn]

TODO:

1. Need to complete an implementation for API keys for JSON hash submission.
2. Need some form of automation to 'process' the submitted files and move them to _PENDINGAPPROVAL state. (for json submissions this is done by default). @ashcrow @dfj @gcmurphy Thoughts?

[ashcrow]

Why not put the fields on the Jar/Egg/Gem structure?

[abn]

@ashcrow thought about that, but decided that it might be better to go with this model as it does not clutter the main collection. And we need to be able to store transient information. And this might get a lot of dump once ingestor goes online. Mostly a cleaner design impov and any changes to info we need here wont affect the rest of the code base. Let me know if you can think of any major negatives.

[abn]

With #75 and #76 implemented, this is considered complete.