Fix flash of Clear Search/Selection buttons after failed sign-in

Move signin control into its own directive

This commit moves the signin and account control (and dropdown) into its
own directive.

To make it easier to understand what's going on at load, I've also
changed the signalling of user signed-in/signed-out state to an explicit
`status` field on the `auth` object, rather than relying on a tristate
of {undefined, null, user object}. This results in templates that are
marginally more verbose, but substantially clearer in intent.

Lastly, I've moved the computation of the `username` and `provider`
properties into AppController so that it doesn't need a `$scope.$watch`.

This is labeled `ng-if="groupsEnabled"` but is within an entire section
which is labeled `ng-if="!groupsEnabled"`.

When an app reload occurs, the 'Clear Search' and
'Clear Selection' buttons would sometimes flash.

This occurred due to an issue where the initial
call to the watcher registered by ng-show to hide
the buttons being invoked asynchronously in some cases.

When the app's route is loaded, the following happens:

 1) viewer.html is compiled
 2) viewer.html is linked
 3) Watchers registered by directives during (1) and (2)
    are run. For the watchers registered by 'ng-show',
    this applies the .nghide CSS class that hides
    elements.

On initial app load, 1-3 all happen synchronously in the
same scope.$digest cycle. However, when logging in with
an incorrect password, 1 & 2 happened in the same cycle
but 3 happened in a separate cycle, with DOM rendering
taking place in a flash between before the directive
was fully ready.

The GitHub issue has more detail and there is some
connection to the 'deepCount' directive but I decided
not to alter that here without sufficient understanding
of the consequences.

This commit fixes the issue by applying the 'nghide'
class to the viewer.html initially and then letting
ng-show _remove it_ when its watcher runs. This fixes
the flash when 1-2 and 3 happen in separate digest cycles
and has no effect if they run in the same cycle.

Fixes #2642

Turn on pyramid's conditional_response machinery

Replace hashids with pubids

Fix extension clobbering embedded H

Merge pull request #2650 from hypothesis/trello-143-make-replies-default-to-group-and-visibility-of-parent

Set group and visibility of reply to that of parent

No longer used

Set up a constraint naming convention for sqlalchemy

Don't expand URIs if the search URI is a rel="canonical"

Upgrade to Angular 1.4.7

Rename permissions.public() -> permissions.shared() and
permissions.isPublic() -> permissions.isShared().

This is more consistent with language used elsewhere in the code, now
that we have groups.

Set the group and visibility of replies to that of their parents, when
replies are first created.

Also prevent the visibility setting of a reply from overwriting the
cached-in-local-storage visibility level. This prevents the following
problem:

- I'm annotating publicly (my cached-in-local-storage visibility
  setting is public)
- I reply to a private annotation
- The visibility of my reply is set to that of its parent, private
- This visibility is then cached in local storage
- I make a new top-level annotation, and now it's defaulting to private
  instead of public, even though the user never did anything to change
  the visibility from public to private, it was done automatically
  because they replied to a private annotation.

Obviously changing the mode from private to public when replying to a
public annotation was also possible.

This means that if the user _does_ change the visibility of a reply, we
_don't_ cache that either:

- I'm annotating publicly (my cached-in-local-storage visibility
  setting is public)
- I reply to a public annotation
- The visibility of my reply is set to that of its parent, public
- This visibility is not cached in local storage because it's a reply
  (and the value cached in the local storage is already the same anyway)
- I then deliberately change the visibility of my reply from public to
  private
- Again this visibility is not cached in local storage because it's a reply
- The next time I make a new top-level annotation, it will still be
  defaulting to public, will not have changed to private mode

In Angular 1.4.x, calling ngModelController.$setViewValue()
does not trigger parsing and validation if the current view
value is the same as the previous view value.

angular/angular.js@5da1256fc2812d5b28fb0af0de81256054856369 made it
impossible for `transformRequest` functions to modify request headers,
so instead we maintain a global header map which is updated when the
session is updated.

The read-only state was not being passed correctly from
the annotation viewer to the markdown editor, possibly
due to the use of the 'ng-readonly' which in turn
set the 'readonly' attribute that the 'markdown'
directive tried to read.

This converts the markdown editor to use the
preferred style of an element directive plus
a 'read-only' attr.

Well this was fun to debug.

Not.

So, it seems that in 1.4 (as opposed to 1.2) Angular Promises are
special, and don't play well with native browser Promises. In
particular, Angular promises don't resolve until a digest cycle, which
means that while this test will pass:

    it('should resolve', function (done) {
       var resolved = false;

       $timeout(function () { resolved = true; });
       .then(function () {
         assert.isTrue(resolved);
       })
       .then(done, done);

       $timeout.flush(); // <- this triggers a digest cycle
    });

This one will not -- Mocha will time it out, because the digest cycle
triggered by `$timeout.flush()` occurs before the fulfillment handlers
(with the assertions and the call to `done`) are registered:

    it('should resolve', function (done) {
       var resolved = false;
       var wait = $timeout(function () { resolved = true; });

       $timeout.flush();

       wait.then(function () {
         assert.isTrue(resolved);
       })
       .then(done, done);
    });

If that were the whole story, I would be merely mildly displeased. But
it's not...

The return value of a call to `.then(onFulfilled, onRejected)` is a
promise of the return value of the `onFulfilled` callback, which is what
makes Promises chainable. If `onFulfilled` returns a promise, then that
is (or should be) the promise returned by `.then(...)`. Unfortunately,
if we actually do this:

    it('should resolve', function (done) {
       $timeout(function () {
          return Promise.resolve('abc');
       })
       .then(function (val) {
         assert.equal(val, 'abc');
       })
       .then(done, done);

       $timeout.flush(); // <- this triggers a digest cycle
    });

Then again, Mocha will time out on this test. This is probably because
the returned Promise resolves on runtime `nextTick`, which is *after*
the call to `$timeout.flush()`, which means it's after the relevant part
of the digest cycle which processes the fulfillment handlers for the
Angular-style promise.

ARGH, Angular. Argh.

Since angular/angular.js@c054288c9722875e3595e6e6162193e0fb67a251,
`angular.toJson` only strips properties beginning with `$$`, and not
`$`. We set properties on annotations (such as `$orphan`) so need to
reimplement the earlier behaviour.

I've also taken this opportunity to translate the store service to
JavaScript.

This shim was used to facilitate the use of a newer version of the
'ui.bootstrap' module with an older version of Angular. Upgrading to
Angular 1.4 renders it surplus to requirements.

Upgrades angular-toastr to a version compatible with Angular 1.4. We now
use the version of angular-toastr from NPM, rather than our own vendored
copy.

Move sort dropdown to top bar

Use 14px for all top bar menu item text
for consistency.

T-91

Update to the latest version of the sort/filter toolbar
icon from the Trello card.

T-91

Align the dropdown menu's top arrow with the
bottom arrow of the menu.

As the styling of the dropdown was adjusted for
its new home in the top bar, it became wider and the
previous alignment of the menu resulted in it disappearing
off the left edge of the sidebar.

T-91

T-91

Dropdown menus were using BEM element naming in some
places and tag name selectors in others.

This updates the styling to use BEM element naming
consistently.

Remove the padding from the links in the dropdown menus
and apply it to the row itself instead.

This makes it easier to keep consistent spacing with
different menu item contents in the dropdowns.

T-91

T-91

When the 'Groups' feature is enabled, move the sort
menu into a dropdrown triggered via a button
in the top bar.

T-91

Replace client-side profile form

Flash confirmation messages when profile forms are successfully
submitted.

Remove the client-side profile forms which are now implemented on the
server. This actually removes a couple of dependencies which we can also
remove. In particular the "tabbable" directive from angular-bootstrap is
no longer needed.

Add server-rendered profile update and notifications settings forms.
Unlike the previous changes I've made to form-handling, these are not
straightforward translations of the forms that existed in the sidebar,
for a couple of different reasons:

- The profile update form no longer has a delete account button. The
  delete account functionality doesn't really do anything: it sets a
  random password and logs the user out. We haven't removed any of their
  personally identifying information, and we can't even tell by looking
  at the database who has attempted to delete their account. We've
  agreed to remove this button until such time as we can implement the
  feature properly.

  In its place is a paragraph inviting users who wish to delete their
  accounts to email support.

- The wording and layout of the notifications update form has been
  tweaked to read more clearly.

Remove get_by_userid()