Document optional, wildcards and Regex parameters
Minor readme cleanup
Fixes Issue and PR #93 - Subscription handling in route computations...

The following use cases must be handled when working with route computations in
the onRun method:

1) Old computation invalidated then new route is run before flush. For example,
the user writes this code:

Posts.update({...}); // invalidate the old computation
Router.go('/someOtherPath'); // go to new route

2) Subscribe to the same subscription between routes should not create a new
subscription.

3) Subscribe to a new subscription in a new route should stop the subscription
from the previous route.

4) New computations must not be stopped because we call stop on the previous
computation. In other words, the new computation must be

Solution Details:

We need to stop the previous computation and set up a new computation for the
new route. But the new computation must be set up before the next flush,
otherwise we'll lose out on Meteor's subscription optimization (don't create a
new subscription in a computation if that subscription has already been created
- e.g. from a previous route). But we also need to stop a subscription if a new
route doesn't re-run it.

Previously, I was setting up the new computation in a Deps.afterFlush callback.
This effectively created a new computation that wasn't stopped. However, it has
two problems. The first is that it bypasses Meteor's subscription logic, and
creates a new subscription no matter what, even if the previous subscription was
the same. The second problem is that there's no reason to wait for the next
flush before setting up the new route. This may have even been causing
performance problems.

What we should be doing is stopping the previous computation and putting the
function to set up the new computation in an onInvalidate callback. Here's how
it works:

A computation's onInvalidate callbacks get called in the current event loop tick
for one of two reasons:

1) the computation has been stopped
2) the computation has been invalidated

So when we call stop on the previous computation and then call
onInvalidate(maybeRunReactively), the maybeRunReactively function is run right
away, because the previous computation is stopped (which implies invalidated).
This also works if the previous computation is already invalidated. We'll call
stop on it anyway, and now it will be marked as invalidated AND stopped.
Initial stab at IE compat, and comments for rendering improvements.

- Note tests are probably broken as I'm working quickly.
- APIs could change as I'm in the process of sketching.
- Ideas are welcome.
WIP - Rendering comments.
WIP - New rendering component for the router.

cc @tmeasday, @piffie, @warsamebashir, @richiebe, @CMToups, @ryw, @eichie,
@payner35, @gabrielhpugliese.

- Doesn't work yet but I wanted to push and get feedback
- The idea is that the Router has a _renderer instance
- This _renderer is responsible for tracking a layout, a data context and one or
  more templates to be rendered into named yields. Each can vary independently.

Benefits:
 - @piffie's idea to allow recursive yields into child templates
 - controller level layouts
 - data context can be preserved across routes
 - templates and layouts can change independently

Example using the raw RouterRenderer:

```javascript
var renderer = new RouterRenderer;
document.body.appendChild(renderer.render());
renderer.setLayout('layout');
renderer.setTemplate('mainTemplate'); // render to __main__ region
renderer.setTemplate('asideTemplate', 'aside'); // {{yield 'aside'}}
renderer.setTemplate('footerTemplate', 'footer'); // {{yield 'footer'}}
renderer.setData({title: 'Some data context'});
```
WIP - It would help if I actually added the renderer file.
Use the new LayoutController to manage layout and template rendering.
WIP - Major cleanup.
WIP - Path handling enhancements, bug fixes, architecture cleanup.

- Part of a weekend process to clean up url handling, including ability to
  handle hashes and query strings properly; and to clean up APIs.
WIP - pathFor and urlFor explicit support for hashes and query params.

- Putting query on the params object was just too confusing.
- Often times the params object is a document itself so to get that to work with
  the Router you have to extend the doc (e.g. Post) with the query params or
  hash. It should be separate.
- Idea is to let user set data context using the {{#with ...}} helper and the
  query params and hash can be set using Handlebars options.hash.
WIP - Make named yield check async.

- Per Tom's comment, we don't need to make sure that the named yield exists at
  the time of calling setTemplate. But if it doesn't exist after the flush, it
  probably means the user forgot to declare the yield so we'll give them a
  helpful warning message. It's just a warning message and not an error. We
  could set varying degrees of warning messages at some point.
WIP - Fix named yield setTemplate check.

- Previously, I scheduled the yield check in an afterFlush callback.
- But if we were already in a flush, that would cause the function to be run as
  soon as all the currently flushing computations were recomputed.
- This would cause the afterFlush callback to be called before the next tick,
  and before the layout and template computations were recomputed, which is not
  what we want.
- There might be a more elegant approach, but this works.
WIP - Don't append query string if query string is empty.
WIP - before/after hook cleanup.

- Redo before/after hooks.
- Run order:
  - instance options
  - inherited hooks from top to bottom of inheritance chain
ignore links with target=blank or ctrlKey+click