Create Peers collection and encapsulate options

Re-factor Peer object to use hard-coded connection options be default,
but allow these options to be overridden at instantiation or invocation.
Introduce targeted calling

This is a "first pass" implementation and needs heavy refactoring.
Implement Peer#getTransport
Encapsulate ICE candidate sharing

By making Peers aware of the Transport, the details surrounding ICE
candidates no longer need to be managed in the application logic.
Extend getMedia to return a promise
Remove unneeded dependency
Ensure media streams are ready before connecting
Re-factor

Remove unused code and simplify deferred handling.
Remove assumption around a single active peer

Although the prototype does not currently support more than one
simultaneous peer connection, this structure should aid in future
refactoring.
Automatically focus on the user name input field
Extend Peer API to use promises

Peer#createOffer and Peer#createAnswer wrap an awkward DOM API that is
better-suited by promises.
Leverage promise returned by Peer#createAnswer

Now that Peer#createAnswer returns a promise, the application logic can
declare a more straightfoward control flow (and no longer depends on the
Q library directly).
Use promises more idiomatically

Promise chaining (as opposed to nesting) promotes maintainability and
readability.
Add modal dialog for incoming calls

This dialog alerts the user to incoming calls and allows the user to
accept or reject the calls.
Remove named functions

Since these functions do not need to be re-used, they can be declared
anonymously in order to clarify the application logic.