Add a settings view template for the server setting, and start to implement
the alternate server setting.

I still have to get the form right, and then implement a proper handler -
maybe viewChanging?  And then plug the spiderOakApp.config.settings value
in to the AccountModel, and ensure that a logout happens if the setting is
changed during a login.

(Also, rename the settingsAccountViewTemplate.html from the typo, setingsAccountViewTemplate.html.)
Whoops - some changes missed in last checkin.  Same checkin message:

Add a settings view template for the server setting, and start to implement
the alternate server setting.

I still have to get the form right, and then implement a proper handler -
maybe viewChanging?  And then plug the spiderOakApp.config.settings value
in to the AccountModel, and ensure that a logout happens if the setting is
changed during a login.

(Also, rename the settingsAccountViewTemplate.html from the typo, setingsAccountViewTemplate.html.)
Merge branch 'master' into issue-151-alternate-server
Refactor the AccountModel slightly so it uses the current
spiderOakApp.config.server value as the basis for the various server
settings.
Rectify the logout process, so that the responsibilities are in the right
places and the UI response to logout can be triggered by anyone:

* Trigger logoutSuccess in the AccountModel.logout() method, after actual
  logout has occurred.  ("logOutSuccess" was being mistakenly triggered.)
* Enable calling the logout method without a successCallback.
* onLoginSuccess in app.js does the UI cleanup, triggered by the
  logoutSuccess event.  It does *not* call AccountModel.logout(), since it
  would be infinitely regress by that method's (now correct) triggering of
  the event.
* MenuSheetView now re-renders itself when logoutSuccess is triggered.
* MenuSheetView now properly calls AccountModel.logout(), rather than
  triggering logoutSuccess.  (I believe it was only appearing to logout,
  before!)

This provides the ground for changing the server setting to do a logout
and have the UI clear, properly.
Implement a view by which the primary server configuration is changed.

If the change happens during an authenticated session, the session is
logged out and the UI is reset.

If the change happens outside of any authentication, the user is returned
to the top-level settings view.

The top-level settings view is updated by virtue of triggering a new
settingChanged event - please use that for other settings changes.

(The css changes are expedient - some thought about organized settings
styles is needed.)
Track the setingsAccountViewTemplate.html typo correction in the test's
index.html, too!
Merge branch 'master' into issue-151-alternate-server
Elaborate server config value, and accommodate in existing uses, to prepare
for real settings.
Preliminary commit of settings facilities, not yet hooked up with
consumers.

Starting with just collection.fetch(), collection and maybe also model
.sync() methods may be necessary.
Use a closure binding instead of .bind() to avoid a bug causing test
failure when running the tests on the command line, but not happening when
running the tests in a browser.  !

I suspect some kind of ghostjs bug, but whatever it is, this circumvents it.
Incorporate server setting object into the server setting UI.
Incorporate new server setting object into the share rooms and and account
provisions.
Remove extraneous fetch and unnecessary change event relay.
Ensure that changes to models propagate to the collection.

I'm need to look for cases where this might cause redundant saves, but I
know it's necessary in some cases, and fairly harmless even if there are
duplicates.
Provide some conveniences for dealing with new settings:

.getOrDefault(id, defaultValue): Get setting 'id' value, or return default.
.setOrCreate(id, value, retain): Set an existing setting, or establish it.
Replace redundant fetches of the form values with the already-fetched ones.
Use the new settings facilities to retain the last add-public-share form's
"Remember" state, within and across sessions.  Easy peasy!
Revamp login so it can be used to probe prospective hosts for legitimate
SpiderOak service, ensuring that settings are not changed without success.

Make both the success and error callbacks include the xhr data, so
that the error response can be examined for conformance to behavior expected
of a SpiderOak server.

Move the change of the server-host specific login location settings to the
success, not before!
Revamp the handling of the server host change, in order to validate.

We dance around a bit to do that and also logout, if necessary:

- We have to go through the error (and possibly success) callback on
  a login test to verify that the new designated address host a valid
  SpiderOak service. (We use deliberate deliberately invald login credentials.)
- We use a further callback, for employment via logout in the case
  that server change is valid and the current session is authenticated.