prepping quarry-data.js for next-gen woodstove API

- first draft of a generic CRUD implementation for Quarry.Model
- the following API requests are tested as working: FQDN search, my jobs list, cardstacks find, hypervisors find, meta 'QUARRY_UI' find

QUARRY-693
changing gears a bit on the "overloaded" find() CRUD implementation

Using separate callbacks for find() vs find(record) usages. This allows for easier disambiguation when handling the API response data (return a model object or an array of model objects?).

Still experimental at this point.
another's day iteration through quarry-data.js

Mortar, MortarBulk, Layouts, and Logging remain unpolished.

Lots of generalization in the Quarry.Model class definition:

- apiCallback(data) for returning the data array
- apiRecordCallback(data) for returning the element at index 0
- modelCallback(instance) for returning a new model instance from the data response array @ index element 0
- modelsCallback(instance, sort) for returning an Ember Array of model instances, optionally sorted by key
- findCallback is an alias for modelCallback
- findAllCallback is an alias for modelsCallback
- updateCallback is an alias for modelCallback
- addCallback is an alias for modelCallback
- removeCallback is an alias for modelCallback
- api(verb, path, params, data) is a generic function for performing a Quarry.ajax() call with the generic apiCallback() and errorCallback() options
renamed api() wrapper function to the (slightly) more descriptive apiData()
fixed inconsistent array implementation in quarry-data.js

Due to a misunderstanding of Ember.Array, we were creating Ember Enumerable objects via "Em.A()". In fact, Ember extends the Array prototype to provide this. From the docs:

“Array is extended to implement the Ember.Enumerable, Ember.MutableEnumerable, Ember.MutableArray and Ember.Array interfaces. This polyfills ECMAScript 5 array methods in browsers that do not implement them, adds convenience methods and properties to built-in arrays, and makes array mutations observable.”

http://emberjs.com/guides/configuring-ember/disabling-prototype-extensions/

Ember.A() is only useful if “prototype extensions” are disabled, in which case the array literals will not be Ember Enumerable objects.

Also corrected this mistaken usage in other areas of the codebase.
renamed Quarry.Serp.search() to Quarry.Serp.find()

two reasons:

- We're now using it in all its CRUD.find() glory
- Slightly more readable code, as search() is a built-in String method
updated App.Asset.update() invocations in the codebase (there was only 1) to conform to new generic Quarry.Model.update() method

Quarry.Model.update parameter signature looks like this:

update: function (name, data)
updated Mantel to call new routepath for 'users' API
preferring the + prefix operator to cast a String to a Number

Minor code inspiration after reviewing Crockford. Putting this into the spike branch for sanity.
working around Ember.Select performance issues

See:

https://github.com/emberjs/ember.js/issues/2386

In our "VM Commission" and "Add Physical" workflows, we were generating bulk build lists, each member of which included several usages of Embers.Select in the template. The particulars of the "VM Commission" workflow, for example, were introducing approximately 600 ms of blocking execution (i.e., total browser freeze) per host.

The workaround:

The "template" page, i.e., the first page in the workflow, remains unchanged (aside from the omission of disclaimer language about the delays which we've fixed). The subsequent page (the commissionVm.specs route state) now employs Ember.TextField for all input fields, even those fields whose values are not open-ended. For those fields, we added some Ember View "onclick" foo (App.OnClickSelectRevealer) that transforms them into an appropriate Ember.Select instance when clicked.

What this does:

Rather than automatically generating and inserting the Ember.Select instances into the DOM, we're now doing so "on-demand". The upside is that progressing through the "VM Commission" and "Add Physical" workflows is seamless. No more 5 second (or worse) delays. The downside is that build jobs requiring heavy customization in the build list will need an extra mouse click for each <select> field that needs to be manually selected. This shouldn't be a common occurence, as those fields (Hypervisor Pool, OS, Disk Layout, Application Type, Production Type, Business Unit, Chef Role) are usually propogated commonly across all hosts. Compared to the presence of obvious application non-responsiveness, this is a win overall.
more housekeeping in the spike branch

Three main things:

- We're now using our build script to wrap the entire App namespace inside a function literal invocation. This has the advantage of enabling the "use strict"; pragma in function context and enforcing it across the entire app.
- We're now using ES5 strict in our 'App' and 'Quarry' namespaces, yay.
- Build script now minifies using uglifyjs; 'index.html' updated to reference the minified files.

Also cleaned up the jslint '/*global*/' directives in our source files.
minor but good form

changing from list to tuple
replaced all usages of $.each() with a native js for loop
squashed two bugs introduced with $.each() replacements

- leftover return statement from old $.each() callback function was causing 'hostIp' Handlebars helper to return early
- App.Serp.find() was not returning an array of App.Serp instances (it was instead returning an array of API response objects)
a totally refactored login paradigm

- no more horrible pseudoclassical mantel.js, replaced (for now) with a simple singleton object (kept the name mantel.js)
- added a login route and controller to support in-app logins (no more URL redirection to a separate Ember app)
- quarry-data.js gets lots of configuration cleanup
- added Quarry.User client API wrapper

There is still some potentially I/O-blocking stuff we'll want to clean up (cookie getters/setters, for example), but this is a vast improvement.
enabled user secret creation during login workflow
added networks availability stats to networks view
added App.NetworkStats mixin

Consumed by the 'Network' and 'Networks' controllers, and the 'Network' route class. Provides the getstats() function that adds IP address usage statistics by way of asynchronous API requests to the ipdb db.
forgot to include 'number' as a identifier type in Quarry.Model.find(identifier)
Networks API now expects 'network_id' as its resource identifier

Which means we no longer have to save the 'network_gateway' property away for passing back to the API in the event that the user changes it.