Merge pull request #6 from redding/kr-source

have templates evaluate given source files
apply locals to template scope as reader methods

This updates the template init api to take an optional locals hash.
Any keys in the given hash will be exposed as reader methods on the
template object.  This allows you to pass in custom local values and
use those values as local methods in template source files.

This also validates that if you give a local named after a template
method, you get the local as expected but it doesn't interfere with
the method aliases.

**Note**: this also updates the alias handling of the node and map
methods.  This technically isn't _needed_ but I wanted to highlight
how the "underlying" node/map logic is separate from the way(s) you
can call it via a template.  So now, the main logic is in "underscored"
methods and the available aliases just alias this main method.  This
seemed to flow nicely with the `__data__` method as well.
Source object for rendering templates

This introduces a new object, `Source`, to use to render templates.
To render a template, create a source object for the given root
of source files you want to render.  Then call render passing it
the name of the file you want (relative to the root and without the
implied `.nm` file extension).  The README and gemspec have been
updated to reflect this change.

You can render templates using fully qualified, absolute paths - the
`Template` object uses a default source with the root `/`.

The motivation for adding this is two-fold. One, I wanted an object
to abstract the manual building of a template and calling `__data__`
to get the rendered results.  Two, in coming featueres I want to add
partial rendering and template source caching.  Both of those features
need to have some shared state between template builds/renders.  In
partial calls, it is preferable to not have to use full qualified
source paths.  To cache template source, I need an object to store
the source in memory.  This `Source` object will aid in both of
these features.

Previously I had thought the `Render` object might suffice but as
I've been implementing things it became unfit for what I wanted to
do.  This removes that legacy object.

Finally, I introduced a `Factory` and moved template handling to
be done using factories in the tests.  This is just a minor cleanup
that helped out with testing this feature.
updated bench scripts to bench against Nm

This reworks the bench helpers to namespace them all under `NmBench`
and commonizes the non engine specific aspects (like the `Logger`).
Then using this common stuff, it adds scripts for benching against
Nm.

There are two benches for Nm: one where the source is built once
and then rendered against many times, and one where the source is
re-built each time.  I did this to make sure I was comparing fairly
against RABL.

The results are stored in `bench/results`.  Nm, even with rebuilding
its source unnecessarily each run, outperforms RABL in all cases.