come up with sane strategy for re-generating sinopia server JS client specs when swagger spec changes

[jmartin-sul]

re-generating the client code itself is easy, since we don't expect to modify it ourselves.

re-generating the tests is currently a pain: if swagger-codegen sees test code there already (even unmodified auto-generated test code), it won't re-generate new test code.

currently, the strategy is to

• have the existing tests committed to git
• blow away the test directory
• re-generate the sinopia server JS client using swagger-codegen (see README).
• git add -p on the re-generated specs, only keeping the desired new and modified test stubs
• discard the working copy changes that replace real tests that you want to keep with re-generated test stubs.

[jmartin-sul]

@cmharlow noted that the swagger library for golang deals with this gracefully by using "handlers", so see if that's a pattern that could be leveraged. when she described that approach, it reminded me of abstract classes and interfaces (actual testing code would just implement the auto-generated interface), but maybe i was misunderstanding that (since i have little go experience). either way, not sure that fits easily with what swagger-codegen does for JS.