Remove unused code

This method (and the scopes it depends on) are not being used anywhere
in the codebase.
Increase coverate around method being refactored
Replace associations with simpler methods

There were a whole truck-load of associations solely here for the
purposes of chaining them together to get a set of published editions
that are related to the current edition's document (i.e. the inverse of
the documents that this edition is related to). Unfortunately the
resulting query was returning the wrong things: it would also return
published editions of documents that have *any editions* (even
superseded ones) that were once related to the edition's document.
This made it impossible to disassociate a detailed guide from those that
have been associated with it, even when they are re-editioned and the
edition_relation is removed on the latest edition. Sorry if that sounds
confusing.

This replaces the chained associations with simpler methods that
generate the appropriate SQL for both inbound and outbound related
published detailed guides.
Simplify and reuse existing code

Instead of treating DetailedGuide as a special little snowflake with its
own associations, we can simply re-use the existing RelatedDocuments
mixin to allow detailed guides to be related to others.
Handle legacy params temporarily

This is so that any editors that have a detailed guide open for editing
whilst the deploy is in progress can still successfully submit their
changes.

This can be rolled back once the code has been successfully deployed.
Don't stomp on other related docs

The related_documents association cannot be used directly when setting
related detailed guides because other types of edition relations are
handled using this association, e.g. policies. This code adds a separate
detailed guide-specific setter that ensures already associated documents
are not stomped on.
Add contextual link to unpublishing guide
Use imagemagick for counting pages in PDF uploads

https://www.pivotaltracker.com/story/show/68617050

PDFInfo was calculating a few other things as well
when we only needed the count of pages. This was
causing this process to be extremely slow (> 50s)
with some PDFs which had a lot of heavy images,
causing request timeouts.

We have Imagemagick installed on backend boxes to
resize the image uploads. Might as well use the
same tool to just count the number of pages in
the PDF, also speeds up the process multiple
times:

$ time identify -format %n ../business_plan_201213.pdf
25

real    0m4.252s
user    0m4.160s
sys    0m0.080s

$ time pdfinfo ../business_plan_201213.pdf
Creator:        Adobe InDesign CS3 (5.0)
Producer:       Adobe PDF Library 8.0
CreationDate:   Tue Apr 17 11:08:59 2012
ModDate:        Tue Apr 17 11:09:58 2012
Tagged:         no
Pages:          25
Encrypted:      no
Page size:      841.89 x 595.276 pts (A4)
File size:      4751247 bytes
Optimized:      no
PDF version:    1.5

real    0m53.529s
user    0m44.923s
sys    0m8.217s
Use shellwords to handle PDF filenames with spaces
Fix "See all publications" link filtering
Merge pull request #1457 from alphagov/signup-links-bug

Fix "See all publications" link filtering
Merge pull request #1451 from alphagov/fix-related-detailed-guides-relations

Fix related detailed guides relations

https://www.pivotaltracker.com/story/show/70347442
Merge pull request #1454 from alphagov/unpublishing-link

Add contextual link to unpublishing guide
Merge pull request #1458 from alphagov/switch-to-imagemagick-for-pdf-page-counts

Use imagemagick for counting pages in PDF uploads
Closed organisations banner
fix Cucumber steps, use size and not count for activerecord association check