refactor ApiResponder and DummyApiResponder to sanity-check all function args

* Fixes #674
* Jenkins: http://jenkins.buttonweavers.com:8080/job/buttonmen-cgolubi1/201/
* Also addresses #552, though not necessarily in the most user-friendly way

Comments:
* I'm nervous about this commit --- between responderTest and the testing the UI does against dummy_responder, most of the regressions should be fine (and i did test a number of things by hand as well, of course), but at the end of the day we weren't previously doing *any* centralized checking or documentation of responder args, and now we're checking all of them based on my understanding of what each function requires.  So i'll be pleasantly surprised if i actually didn't break anything.
* That said, i also think we need this --- the addition of ApiSpec is a piece i've been wanting, to make sure dummy_responder and responder both have the same expectations about arguments and syntax.  And the fact that we get things like e-mail address validation as a side effect is very nice, because i was worried about having createUser try to send mail to malformed addresses, and nothing stopped that before.  And i think there's a lot of room for nervousness about "what happens if i send a non-integer/non-string/non-array to that function?", and this should mean we don't have to worry about a big chunk of that.
* I concluded that i didn't need to do anything about cookies --- we never add anything to the DB based on a user-provided cookie --- the *only* thing we do with user-provided cookies is try to match them using DB select, and this is exactly where SQL prepare should protect us.  So never mind that.