improve [forms] resource

here's what i'm thinking, at a high-level, based on existing forms resource and the clean code in https://github.com/nickjackson/forms :

in the 'view' directory there is a single view (.html and .js) called 'method' and two dirs called 'inputs' and 'outputs' each full of views.
- this means we remove get, update, destroy, find, all views. the rationale is that we want to generate forms for any possible method that work correctly for that method, without the necessity of hard-coding in functionality. also it should reduce a lot of duplicate code. if it turns out we do want special interfaces for those methods, we can add them as separate views later.
the 'inputs' dir should be about the same, ie. be able present a view for each individual input type that is necessary to call the given method.
the 'outputs' dir should be similar to 'inputs', ie. be able to present a view for each output type that is necessary to display the result of the given method call.
- this needs a schema for the return values (https://github.com/bigcompany/resource/issues/17)
- do we just do nested tables for objects and arrays?
in calling the 'method' view: if there is data in the options, it will fill the fields with that data. i believe this is also something the 'array' and 'object' inputs must rely on, as we can have the array/object input create an add button that sends a get to the current page with a new empty element in the array or object, or one less element for remove. if the action in the options is 'post', it will try to execute the method. if there are any errors, we display them above the form.
form templates should be compatible with bootstrap, yet class names used for query selection should be independent of bootstrap so that it would be possible to use a different styling framework
66, for the reason that we want to use the previous style of route for https://github.com/ahdinosaur/bigspace/blob/master/resources/un/index.js#L92, it is more uniform and intuitive, and it removes the need for confusing special cases of how to link within forms.
lastly, we need proper tests.

cc @Marak, as your feedback would be appreciated.

checklist (please add related tasks here):

[x] get 'method' view working for .get method
[x] get 'method' view working for .create method
[x] get 'method' view working for .update method
[x] get 'method' view working for .destroy method
[x] get 'method' view working for .find method
[x] get 'method' view working for .all method
[ ] use bootstrap documentation to make a standard form layout
[ ] add 'array' inputs view
[ ] add 'object' inputs view
[ ] add output schema handling to 'resource' module
[ ] add output schema to bigspace resource methods

...

ahdinosaur / bigspace

improve [forms] resource #72

66, for the reason that we want to use the previous style of route for https://github.com/ahdinosaur/bigspace/blob/master/resources/un/index.js#L92, it is more uniform and intuitive, and it removes the need for confusing special cases of how to link within forms.