Implemented a new API for writing visitors and transformers using recast

see the tests I placed in ./tests/trasnformerAPI.js for examples on how to use the API

The general idea is that we expose a new `recast.visit()` method that allows traversal of an ast tree that was parsed through recast. 

We also expose `recast.builders` and `recast.namedTypes` to avoid having to import ast-types from recast before getting to those objects.

finally, I exposed the convinience functions `recast.genCompile` and `recast.genParse` to allow an easy way to supplement a transformer with the ability to convert `code-string -> code-strting`, `code-string -> AST` and `AST -> AST`.


The new transformer API allows defining visitors objects that contain specific functions as properties with a set name (such as `visitIdentifier`, `visitFunctionExpression`, etc.). Once these visitors objects are created, they can be easily converted into a standalone transformer (inspired by the common use-cases of projects such as es-next), or simply used with the new `recast.visit()` function to visit an ast tree. The underlying visitor functions require an explicit call to `this.traverse()` which is used either to continue traversal of the current node (if more than one functions are designed to visit that node), or move on to traversing the children of that node. Aside from that, visitor functions can make use of `this.replace()` and `recast.builders` to replace the current node with a different AST node. The order in which `replace` and `traverse` are called can support in-order or reverse-order traversal.
In the future, I want to support visiting subtypes, so that (for example) you could implement a method called `.visitFunction` to visit all `FunctionExpression`, `FunctionDeclaration`, or `ArrowFunctionExpression` nodes.

To do that well, I think we need to do some preprocessing of the visitors so that we have a fast mapping from all possible AST types to the name of the visitor method that should be called.

Something to think about, as we get closer to the ideal traversal interface.