Use FactoryGirl.build_stubbed instead of a hand-rolled solution.

`FactoryGirl.build_stubbed` takes care of all this (and more).

I had run into problems with the previous implementation where, because
the "stub record" was still an instance of the `ActiveRecord::Base`
subclass (albeit with lots of stubbed method), and because its
`#new_record?` method returned `true`, it was possible for a database
query to be initiated by something as simple as inspecting the record or
calling an association method.

This problem was compounded in the cases I saw, because Mocha tried to
report the unexpected invocation of `select` on the `ActiveRecord`
connection, but in doing so it also wanted to list the stubbed methods
on the record. The latter caused a recursive call to the record's
`#inspect` method and an eventual stack overflow error.
Sort by timestamp then by document_id

Publications get a date for public_timestamp. This can cause many
timestamps to be the same. In those instances the order which the items
came out of the database was non-determanistic. This will ensure that
they come out in a pre-defined order, even if document is editioned.

https://www.pivotaltracker.com/story/show/45188181
Revert "Reverting "Data migration to add mainstream categories for DCMS""

We have the correct mainstream subcategories now.

This reverts commit 0a8d509790e1282e8116fa64a05835485c1c45b2 to reinstate (a corrected) commit 7fe82c9a425e61ee5dbfb7c8ee92f8ad825668b5.

For: https://www.pivotaltracker.com/story/show/45057197
Make DCMS migration idempotent

We need to run this manually on production urgently, so best to make
this work without errors.
Revert "Use FactoryGirl.build_stubbed instead of a hand-rolled solution."

This reverts commit 13237e4ea7e54c4d3bc9bd8d244fe08ff0655b2f.

For some reason this was causing a seg fault on CI.