Retrieve organisation_slugs from site YAML
One site can be owned by multiple organisations on import

- We only create this relationship for the extra organisation slugs,
  not the ones that were there originally, i.e. whitehall_slug.
- Fix some whitespace between {} in a block.
Ensure that site-org relationships always reflect organisation slugs

- When an organisation decides that it doesn't want a
  sub-organisation editing mappings anymore, we can remove the
  sub-organisation's slug from organisation_slugs in the YAML and the
  import will remove the relationship. That way, we don't have to
  manually delete the rows from the database.
Improve test coverage

- When multiple organisations are added, then one is deleted from a
  site, the relationship for the other still exists.
Add a can_edit_site? method to the User model

- Replicate the existing permissions on can_edit?, referring to a
  site rather than an organisation.
- Add very similar tests for this new method, referring to site
  permissions.
Add a nested context block to shorten context descriptions
Change can_edit? in MappingsController to use can_edit_site?

- Fix a failing Cucumber spec because we updated the message to no
  longer read "edit mappings for site" as we refer to site, not
  organisation.
Show edit buttons when the user can edit a site's mappings

- Show users an edit button if they can edit a site within an
  organisation, so they can edit their site's mappings (e.g. BIS ->
  GO Science). Before, users who could edit a site through the new
  permissions wouldn't have seen the edit buttons because they were
  organisation-specific.
Show editing permission per site on the organisation page

- Replace the flash message about editing organisations with a table
  column detailing whether the user can edit a specific site in the
  table.
- Add new Cucumber specs to test this new table behaviour. Make these
  specs DCLG-specific to not have to wrangle too much with Cucumber.
Now can_edit_site? works, remove can_edit? and its associated tests

- We've replaced it with can_edit_site? which takes a site instead of
  an organisation and uses the same permissions.
Using the new site-org relationship, determine whether a site is user-editable

- The site-org relationship is the new one that gives the ability to
  specify multiple organisations who can edit one (or many) sites.
- Add some tests for this behaviour.
- Fix whitespace in a curly brace block.
Rename the new relationship to extra_organisations to be less confusing

- Before, it was named organisations, which was confusing as there's
  also Site.organisation. The new name distinguishes the meaning of
  the relationship to be other organisations that can edit the site.
- The Site.organisation relationship is the organisation that owns
  the site. Bouncer uses the Site.organisation_id field, so instead of
  referring to the same thing in different ways in both Transition
  and Bouncer, we've created a new relationship and kept Bouncer's
  the same, as Bouncer doesn't need the new behaviour - it just needs
  to know who primarily owns the site.
Rename organisation_slugs to extra_organisation_slugs in site YAML
Rename the organisation method in the User model to own_organisation

- This means there are fewer things named organisation and the fact
  that in this case it's the organisation the user belongs to is
  easier to see and understand.
Show extra sites on an organisation's page

- Define the HABTM relationship for organisation_sites in the
  Organisation model, not just the Site model.
- Move the sites table in show.html.erb into its own partial,
  duplicating and including it twice to have two tables - one for
  sites and one for extra sites. Now users can see what sites they
  are allowed to edit through their organisation, and what sites they
  are allowed to edit through another's organisation - i.e. BIS can
  edit all of bis.gov.uk, and GO Science can edit its mappings on
  bis.gov.uk, but GO Science doesn't have a site itself, it's
  contained within BIS.
- Tests for this have been written in RSpec, not Cucumber, as an
  experiment and to avoid Cucumber's overheads. This seems easier to
  read as the tests are mostly setup of organisations and sites and
  extra sites that users can edit, the assertions are fairly simple.
Organisation#with_sites_managed_by_transition scope uses extra_sites

- Treat the FK relationship between a site and its org plus those in
  the many-to-many as functionally equivalent for the purposes of
  showing the organisations. In practice, this means that orgs like
  "Go Science" that don't have their own site will appear as an org
  with a site in the orgs list.
- This Cucumber spec tests whether sub-orgs with no actual sites, but
  editing abilities on other sites (i.e. GO-Science -> BIS), will
  show up in the list of organisations. Users looking to edit
  GO-Science's mappings on BIS might not necessarily know to look
  inside BIS.
Remove the 'permission to edit?' column based on @fofr's feedback

- He thinks that users won't need to look at it, because they go to a
  page specifically knowing which sites they can edit and which they
  cannot.
Show only one table on the org page, containing sites & extra_sites

- Move into one table following feedback from @fofr, as it is neater.
- For sites that are owned by a different organisation than the one
  the user is looking at, include that information on a greyed-out
  line underneath the site URL.
- Remove `with_mapping_count` site scope that was in use in the
  OrganisationController. It didn't seem to be doing anything.
- Add horrible numbers of spaces to the test - it's interpreting
  indentation as spaces, so the test was failing without line breaks
  or this number of spaces.
Remove 'breakable' class from org title

This class allows URLs to split at a . if they are too long for a
single line, rather than only on spaces. Since organisation titles
have spaces in them we don't need this class here.
Add a scenario for trusted organisations

* Organisations that are trusted by another organisation to edit
  their mappings