If Meteor.settings.public exists, make it available on the client as well.

(Suggested by @jagill at Meteor Dev Shop 0!)
Upgrade useragent to 2.0.1.

Will be using for the appcache.  I tested 2.0.1 and it seems to work
fine.  I figured that all else being equal it would be good to use the
latest version to give us the most recent user agent matches, and so
that if we had any bug reports we wouldn't be out of date.
Merge branch 'pr-672' into devel
Added all people to the docs, alphebetized by first name
Wrap all of accounts-base/localstorage_token.js in a closure.

This way we don't modify window.userId.
Generate a bundler manifest.

Creates a manifest of the static files delivered to the client, for use
by the app cache.  The manifest is also designed to be usable to generate
etag's for issue #626.

In the original bundler code `self.css` and `self.js.client` starts
out as an array of os-specific file paths and later becomes an array
of URLs (including query parameters).  While I tried to minimize code
changes to avoid creating extra work for the engine project, this
turned out to be too crazy to deal with.  In this version `self.css`
and `self.js.client` stay as file paths, and _generate_app_html now
pulls the client URLs from the new manifest.

This PR is thus proposing a design where the bundler manifest becomes
the source of knowledge about client static resources included in the
bundle, and is then used to generate the app html, the app cache, and
perhaps etag's in the future.  (If it made sense then the `load` list
of server Javascript files could also be folded into the manifest,
making the manifest the source of knowledge about all static
resources... but the code in this PR don't include any steps in that
direction).
Code review updates to the bundle manifest.

`__meteor_bootstrap__.bundler` => `__meteor_bootstrap__.bundle`

`bundle.bundle_dir` => `bundle.root`

Rather than placing app_info/appInfo containing the manifest in the
bundle object, instead I'm now placing the manifest directly in the
bundle object.  A) no code currently uses bundle.appInfo.load; B) if
someday we expand the manifest to also include server side resources
than we'd be getting rid of `load` anyway; C) I think it reads better:

`bundle.appInfo.manifest` => `bundle.manifest`

cp_r now returns a list of os-specific relative file system paths as
strings, instead of paths as arrays.

I changed the normalized "path" field in the manifest to be a relative
path instead of an absolute path (`"/static/cat.jpg"` =>
`"static/cat.jpg"`).  This felt better when looking at the manifest; I
think because the path is relative to the bundle root.
Merge branch 'pr-667' into devel
Upgrade bootstrap to version 2.3.0
Merge branch 'devel' into ddp-pre1