Refactoring py2http to use the chain-of-interpreters design.

[thorwhalen]

For illustration of the way not to do it, see this closed issue and it's comment:

In general, we want to apply the convention rules as early as possible, expanding our input objects (e.g. functions) to the long language that explicitly tells the subsequent transformations what to do (here, for example, create the "name" field for a route, instead of endowing func with a name to be used later.

The chain-of-interpreters, which i2mint tools use, or should use more often, is a chain of transformations that transform the input objects--along with the configuration and convention--into a "long language" that gives explicit instructions on how to create the target. In the case of py2http, the input is one or several python objects (e.g. functions) and the target is an "app" object that has everything it needs to launch an http service serving those objects via an http interface.