Tests for PasswordProtectedModelBase.composedUrl(), including one that
exposes an oversight in providing for urls that already have query
parameters.
Provide in PasswordProtectedModelBase.composedUrl() for urls that already
have query strings.
Merge pull request #248 from SpiderOak/issue-247-password-protected-composedUrl

Issue 247 password protected composed url
Fixes #240

However, I would like to do a more thorough review of file types, so no pull req yet.
Merge pull request #254 from SpiderOak/issue-240-mime-types

Fixes #240
Test with a password that includes characters which break window.btoa.
Hebrew will do.  (Testing just latin characters wasn't enough.)

Also, restructure the AccountModel tests to initialize spiderOakApp, so the
AccountModel tests can be run without the other.  (Eg, via:
   ./node_modules/.bin/mocha-phantomjs www/tests/index.html?grep=AccountModel
).
escape() passwords and usernames before forming Basic auth with them.
Otherwise, window.btoa() raises an InvalidCharacterError: DOM Exception 5.

According to empirical testing, this seems to be exactly the encoding that
the server is expecting.
Pinning iScroll to v4

And a small but pointless change to store.js
Merge branch 'master' into issue-256-login-btoa-chars

for the build fix that tracks iscroll's relocation.
Merge pull request #257 from SpiderOak/issue-256-login-btoa-chars

Issue 256 login btoa chars
version bump for beta
Add a test establishing that blue-style logins, where the username for
login differs (by more than alphabetic case) from the username base32
encoded in the URL, are handled properly.
Refine the provision that refuses the server's acceptance of logins with
usernames that differ from the official username by alphabetic case, so it
only refuses that difference.  It must accept other variations, to allow
for blue-style logins where the login username and username base32-encoded
in the URL are completely different.
Merge pull request #266 from SpiderOak/issue-265-blue-login-problem

Issue 265 blue login problem
Fixes #244

Seems the FavoritesView was the only main level view to NOT have `destructionPolicy: "never"` set.
Merge pull request #268 from SpiderOak/issue-244-navigation-bug

Fixes #244
Merge branch 'master' into issue-229-active-settings-toggle-body
Remove the interlock stuff - much too cumbersome, and not a good approach.

Try setting z-index.  Not currently sufficent, and we will probably be
switching to a different switch mechanism anyway, but worth recording.