Copy individual properties into vm.annotation explicitly, instead of blindly
copying all of domainModel into it. This allows us to see what's in there and
start making decisions about what should/shouldn't be in there.

Since vm.annotation.permissions is (soon) no longer going to be used,
don't validate it in validate(), validate model.permissions instead.

The templates read vm.isPrivate() and vm.isShared() and call vm.setPrivacy()
so vm.annotation.permissions just isn't needed.

The controller modifies domainModel.permissions when the permissions need to
change.

vm.annotation.permissions is still there, we just don't use it anymore, in the
future we should not copy it into vm.annotation at all.

The templates read vm.group() (which returns domainModel.group) and never write
any group, so vm.annotation.group just isn't needed.

The controller modifies domainModel.group is the focused group changes while
creating a new annotation.

vm.annotation.group is still there, we just don't use it anymore, in the future
we should not copy it into vm.annotation at all.

Clarify the pattern of using the presence or not of model.id to test
whether an annotation is new in AnnotationController.

Don't change model.group in AnnotationController when the currently focused
group changes.

model is supposed to be a read-only domain model, change vm.annotation instead.

Changes to vm.annotation are copied over to model before saving model to the
server.

To make this work vm.group() should return the current group of the annotation,
accounting for any changes made to vm.annotation but not saved to model or to
the server yet. It should return vm.annotation.group not model.group.

Similarly vm.isShared() should be based on vm.annotation not on model.

Also remove some code in thread.coffee that was deliberately hiding new
annotations that don't belong to the focused group (see commit
272b2432c48a2d6bf890daa863e92f3a678b27b5). This is no longer the desired
behaviour - when changing groups any new annotations move to the new group with
us (and the GROUP_FOCUSED listener in AnnotationController will update
vm.annotation.group to match).

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.