This avoids a redirect in the common case that JS is
available and has loaded.

 * Refactor the controller setup for the home route
   to be consistent with how it is handled for other pages.

New homepage design

 * Add the flashbar to the header so that it shows up
   on all routes that might need it. Otherwise flash
   messages will only appear when the user visits
   the homepage

 * Add styling for the flashbar

Our script and style files are split between h/static/scripts
and h/static/styles in the source tree.

When updating Bootstrap however, these files are part of a single
archive and it is useful to have the config.json file, the CSS
and the JS all in one place.

This also updates the Bootstrap build with styles for
alerts which are still used by the flashbar.

Keep the existing grey background and Lato font for
pages on the site other than the new homepage.

Those pages will be updated in separate design iterations.

Elements of new homepage design are still in flux.
To facilitate integrating the work done so far on the new homepage,
re-introduce the old homepage and serve that at '/' and serve
the new homepage design at '/new-homepage'

Having a variable called 'isChrome' and then explaining why
we are trying to work around Edge's spoofing that aims
to deal with exactly this kind of check is silly.

Instead make it more explicit that we are checking for
support for Chrome _extensions_. If Microsoft Edge supports
all the APIs we need in future for that, great, we'll let
them use it.

Microsoft Edge unfortunately has to spoof various aspects
of the Chrome environment, including having the string
"Chrome" in its UA string and it also exposes a 'window.chrome' object
in the DOM.

Make the check for the Chrome extension stricter by checking
for 'chrome.webstore' instead.

The logic on the installer page was completely OTT for the task
at hand. Simplify it, add tests and fix a minor issue where it was
shown when testing the page in responsive mode in Chrome
devtools where the User Agent is spoofed but 'window.chrome'
is still available.

The dropdown arrow used to be rendered with a unicode
character that was not in the requested font (Source Sans Pro),
so its apperance would vary depending on whichever font the browser
fell back to.

I considered using an inverted '^' char with a transform applied
but opted for an SVG instead which is easier to work with.

Rename the variables used for the size and position
of the laptop image for consistency with the block names.

 * Use the correct 15px font size for the install button
   label and link input field

 * Make the mobile nav menu background full-width on mobile
   and indent open sub-menus

 * Use regular rather than light font weight for news item
   snippets

Use a smaller max-height so that the content below
the menu moves down at roughly the same speed as the menu
content slides down when the menu is opened.

Follow the naming pattern of <component>__<element> more
appropriately. Several classes used names with a <page>__<component>
format instead.

As per design specs, the left edge of dropdown menu items
in the header nav should be flush with parent items.

When visiting the Hypothesis homepage on mobile devices,
only show the Via link.

The bookmarklet is not practically installable for most
Android/iOS users, although the link is still there below
the laptop if anyone really wants to try.

Chrome extensions are currently not supported on mobile :(

 * Add margins between screen and content
   when the device width is less than the max width
   of the main home page content

 * Make the social media icons in the footer larger
   and add spacing below them to make them easier to
   hit on touch devices

 * Make the dropdown menu indicator slightly larger and
   open the dropdown menu when clicking it, as opposed
   to just when clicking the menu item text.

 * Make the hit target for links in the menu larger by
   making the link take up the full width of the item

The laptop screen on the homepage takes a
1240 x 725 image.

This parses the feed when the page is loaded for the first
time and fetches the most recent 3 items from the feed.
The title, date and summary are then reformatted and rendered
into the homepage.

This also removes the redundant instructions to
add the 'showHighlights' configuration for the embed,
which is no longer required.

Use a custom minimal build of Bootstrap, providing only
the modals for the front page.

The full version of Bootstrap is still used by the admin
parts of the website.

 * Re-implement logic for showing browser-appropriate installation
   option

 * Tweak the border styles on the proxy link form

 * Split out the header and footer of the design
   into their own templates to facilitate re-use in WordPress
   and other pages on the site

 * Rename the existing logo-only header to logo-header.

 * Rename 'nav-bar' to 'header' since that is a better description
   for how it is used

 * Move inline styles and scripts out of the template and into
   appropriate JS/SCSS files

Update the style of the navigation bar on the homepage
to the new design from https://trello.com/c/h6kQMQG8/

Consolidate API validation

Move all templates into `templates/` directory

It would be nice if each module could be responsible for their own
templates, but in reality nearly every template forms part of a large
tree of templates, extending base layouts, and so on.

In the interests of consistency, it makes sense to have all templates in
the `h/templates/` directory rather than some being in `h/templates/`
and some being in their respective module directories.

Don't 500 when non-object JSON is POSTed to API create

Fix standalone annotation page realtime updates for replies to replies

Fix standalone reply pages

This commit fixes a bug where a standalone annotation page only receives
realtime updates for replies on that page if the top-level annotation on
the page is also the root of its message thread.

The annotation `references` field contains the ids of all ancestors in
the message thread, from oldest to newest -- that is, the earlier in the
references field an id appears, the higher it is in the message tree.

In order to receive realtime updates for all messages in the part of the
thread displayed on a standalone annotation page, we need to ask for:

- all updates in which the id in the URL matches the id in the
  annotation (i.e. updates to the top-most displayed annotation, which
  may itself be a reply).

- all updates in which the id in the URL *is contained in* the
  `references` field of an annotation (i.e. updates for any annotation
  lower in the message thread)

Previously, this code requested all updates in which the id *was the
first entry* in the references field, which is only ever true for the
root of a message thread, meaning that it only ever worked on standalone
annotation pages for top-level annotations, and not on pages for
replies.

This commit is a partial revert of 4628b26, affecting standalone
annotation pages only.

That commit changed the AnnotationViewerController (the component
responsible for standalone annotation pages) to make a single request to
the search API to load an annotation and all its replies, rather than
two requests -- for the annotation and then for its replies.

This works just fine so long as the top-level annotation is not itself a
reply. In that case, however, the search endpoint returns nothing, as
the (temporary) `_separate_replies` parameter ensures that only
top-level annotations are matched.

This commit switches back to making two requests to populate the
client-side data structures for the standalone annotation page:

1. To fetch the annotation referenced in the URL (which may itself be a
   reply).
2. To fetch any replies to the annotation referenced in the URL.

Fixes #2775.

Add a robots.txt

This adds a basic robots.txt which prevents indexing of pages under
`/groups`.

2728 misc annotation controller refactors part 2