beginning tests of the system scripts

this should help refine the jasmine integration, and i'm aiming to
expand the script execution model to allow multiple threads of execution

and while i was in there, i killed that stupid API test, since this is
more like what i was aiming for there anyway.  there will of course need
to be higher-level integration tests of the API pieces, but this is
meant more as unit style
introducing script configuration

right now, this is the gateway drug to multiple script execution threads, which is now, i believe, low-hanging optimization fruit, because I have sooooo many script execution types being added, and by design, they are all isolated and totally ready for this sort of thing.  one hopes :D
Repackaging uris

Why have two ways of doing one thing? uris are not only a server need
running the system specs in the integration project

no real need to have them packaged up with everything else, i think
additional API script test

and i am done. woof
documentation
the specs have to load from inside the jar

gonna think about this one...
moved the ScriptResourceType

a hidden interdependency.  for no reason, at that.
making require mockable

or at least renameable, for mocking purposes.

also removing a dead end class that isn't needed
ensuring that script errors propagate out to the tasks

during spec execution i noticed certain types of errors would be
ignored, so that's not the case anymore.  also testing that behavior
testing some more

need to understand specifically how to test the output of makeSetter. also need to understand more about the destination

it's funny to spend time on this particular spec since the routes around even used yet.  but that'll change... soon