Splits the bulk data creator into four processes, one per object type.

Before this change creating bulk data was CPU bound on a single core when generating json files and was then IO bound while compressing those files. This change makes things more chaotic, but makes it so that bulk data archives for all four object types are begun simultaneously. They will finish at separate times due to their varying sizes, but we will no longer wait for disk to finish before starting on CPU tasks, since it will all be running at the same time.

I expect that this could be further refined by adding more granularity, but the current code was a simple change, so I rolled with it. I expect things will look like this during processing:

The command is run, four processes are spun off:

   - Documents --> JSON
   - Audio --> JSON
   - Jurisdictions --> JSON
   - Dockets --> JSON

 These will finish at differnt times. When Jurisdictions finishes (it's smallest), it will be compressed and put on disk while we wait for Audio to finish. When that finishes, it will compress and go to disk, and so forth. I exect that since Documents are so much larger than anything else, they'll still finish last despite starting first.
Merge remote-tracking branch 'origin/master'