Lookup() refactor

This is a first draft to address #539.

@cmather I think this is a reasonable first try at the change we discussed (TDD with TinyTest was pretty cool :+1: ). 

However, I struggled to write the DOCS.md update, and I began to have some concerns about where this leaves us:

* I tell the reader to "avoid directly querying the `options` object on a route, as it may not return the correct value." Huh. So we have options sitting there, discoverable and with useful-sounding names, but they may not be definitive.
* I tell the reader that "Valid lookup items include 'template'."...and stopped, because I couldn't think of anything else a typical reader would want to look up. I was going to add "path", but in fact even that doesn't work, because the path property on a route controller which defaults to an empty string, `options.path` will return `undefined`

Part of the question here is where we would want to save options as static properties (like `path`) and where they should use a dynamic lookup (`waitOn`).  `template` used to be saved statically (the fact that it disappeared off the route controller is what caused me to start looking at this issue), and I would argue that maybe it should go back there. There's not much value in dynamically calculating it on each reference, and I would argue that the template is something a "normal" app dev would want to know from time to time. `waitOn` and `regionTemplates`, on the other hand, are really more internal/package developer things that I didn't feel right adding to the middle of the docs.

You'll have better context, but here's where I think I come out:

* `template` should go back to being a static property like path. I guess the same logic would follow for yieldTemplates and regionTemplates – could go under a `templates` property if clutter is a concern
* the `options` object in the route controller should go away, or be made private, or at least stripped of static settings (and those should be saved elsewhere). Direct access to path and template in `options` does not give reliable results, so users should be discouraged from looking here.
* `lookup()` would be reserved for hooks, etc, that need to be dynamically compiled. Does this make it more specific, perhaps indicating a name change? And I see there is already a `Router.gethooks()`. 

This for me is putting the .lookup() concept in doubt a bit. I'll wait for your reaction, and we can look at options to more forward. The code in this PR is clean on TinyTest (and includes fairly complete tests except for `waitOn`) and seemed to work fine on a simple setup.