link rel=js href=#id works properly on depedencies

Templates can indicate JS dependencies with <link rel='js'>. redoak supports
adding embedded script tags as depedencies by specifying href='#scriptid',
where 'scriptid' is an ID for a script element in the template's owner doc.

This commit fixes a bug where preventing oak files from including embedded
template script dependencies if the template came from another document.

I gave generated JS tests their own directory in anticipation of adding a test
for this bug, but due to the way the environment gets set up in gentest, I
can't really test the fix. The reorg is still better than before, so I'm
including it anyway.
New debug mode for redoak server.

Although not quite mature, redoak's basic architecture is stable enough to need
some great tools. This is the first step towards that.

You can now navigate to localhost:3000/debug/ in order to see the entire redoak
data structure in memory, including the file data and the tree itself. The
JSON viewer is rough but functional.

Some potential future use cases:
* Examine files and their dependencies.
* Look at how redoak parsed the templates, with the ability to navigate to
  individual widget pages.
  * Examine the autogenerated JS/CSS/HTML.
  * See warnings or suggestions.
  * Possibly autogenerate your own JS.
  * A sandbox for using widgets.
Move fileobj operations to its own file.
Legwork for own template parser.

redoak has been using mustache to do its parsing. It was a great place to
start, but has become not ideal due to redoak's partial support for it in
server-side template rendering.

redoak currently has a hack to know all the unbound variables for a template,
which it needs when it figures out what DOM elements need to be modified when
a template changes. With an AST, this gets much easier.

Additionally, this will eventually remove the runtime mustache dependency by
generating the final innerHTML string in the autogenerated code.

This is the first step towards a smarter redoak that generates smaller, smarter
code.
Mustache no longer needed for runtime.

Generated JS code is now clever enough to look at a template and make JS that
directly concatenates strings to generate HTML. redoak now has an HTML
generator generator!

Next up: get rid of server side uses of mustachejs for consistency.
Fix tests and remove mustache completely.

Mustache is now no longer used by the server code, and this uncovered many
bugs. The mustache derivative is being called "oakstache" for the time being.

It's now possible to bring loops and inversions to the generated JS. We could
even start generating code for lists of widgets, though there's some tough
work there for updating an existing widget.
Add escaping support.
AST should be generated from expanded data.
Legwork for walker.

After spending time thinking about how redoak can be used outside of a node
stack, I started playing with a declarative mini-language. The language
specifies a walker that allows you to reduce JSON to a string.  Like CSS, rules
tell the walker how to render the JSON.

The walker can be used with redoak. By making a POST to the development engine
or running redoak via the command line, a user can generate server side
templates for their specific stack, which she can then use to render widgets
or the root HTML on their server, if they so wish.

This idea seems powerful to me, but I'm worried it will be confusing. I have
no idea if this idea will stick.
Rough implementation of walker with tests.

The walker works! You can now write walker programs that can walk JSON.  Next
steps: use it in render.js:htmlJs and add redoak CLI for generating HTML or
templates.
Syntax change: more flexible, less CSS like.
Reorg, walker fun page, and walker used for htmljs

Lots to cover over the past few days:
* walker is starting to work beautifully, and is covered by a decent amount of
  tests at this point. We now use it for generating the html JS, and I suspect
  it has a broader set of applications than just that in redoak.
* walker has a toy page you can get to with `redoak widgets/walker.html`.
  I used this page to instantaneously debug walker. I continue to be convinced
  that this is the way to program all the things.
* lib was looking a little hefty, so I moved the gentests and reftests out to
  root. I also put some redoak generating templates into templates/ and
  moved jsonviewer to the new widgets/ directory.

walker seems mature enough to use for its original purpose: as a way to
generate templates

The next big step is to get the walker toy onto debug. This will let devs write
programs directly on /debug to get a feel for the walker language. It could
include a mustache example.
Support specifying strings in walker.
Tabbed view for walker toy.
New convenient way to implement and call methods.

The awkward way before:
Widget.event('mywidget').listen({...});
mywidget.emit('mymethod')();

The new way:
Widget.implement('mywidget', {...});
mywidget.mymethod();

util events have made writing reusable code a chore, and don't use JS coding
norms. Calling a method for a widget shouldn't need to invoke a method that
returns a function that needs to invoked. This moves widgets a step closer to
how you would normally create and manipulate objects in Javascript.
First try at new debug page.

Walker toy has been added to debug page, but it's now clear to me that walker
needs a way to handle arbitrary key values for objects. I'm thinking it should
concatenate the values together with {{.}}, just like arrays.
Some bug fixes.

* Bug 1: client side templates were not properly working for {{#block}} when
         block is not an array.
* Bug 2: walker had a bug with complex filters, which caused things like
         {a b=5} to only check the first part.
Rough support for generic frameworks
New use syntax (tests still broken)

Specifying JSON in a use tag is no longer permitted. Instead, you may specify
objects recursively using the "obj" tag, which will add elements to the
"children" key of the JSON object.

With this update, we lose the ability to specify objects recursively except
specifically through a "children" key. In return, we get a syntax that works
better with common use cases that need to include many lines of HTML.

For example, a blog post app might now look like:

<template mx='blog'>
  <div class='entries'>
    {{#children}}
      <use mx='blog.item'></use>
    {{/children}}
  </div>
</template>

<template mx='blog.item'>...

<use mx='blog'>
  <obj date='Dec 25 2012'>
    <p>It's Christmas! ...</p>
    <p>Lorem ipsum...</p>
  </obj>
  ...
</use>

Before, we'd have to specify an awkward JSON representation of this object.

This new syntax also requires a smarter use tag, which I am working on next.
Get use tags working properly again.

Use tags are now evaluated when the template is expanded, which ended up being
simpler than before.

Other notes:
* walk has changed the way it works with arrays.
* some minor fixes to todo app, jsonviewer, and tabs widgets.