Bridging classes to allow python and java to intermix.

The messy details of actual embedding python in the jvm, aside from interpreter
state, go here.  Don't expect a pleasant ride.  If you want to create a new python
type or function, something that requires knowledge of the C structures behind
everything that knowledge should be encoded in this file.

Wrapper for simple logging.  Use tools.logging ns directly for more
advanced usages.

Base support for python objects and python->jvm interop.  At this level (without
interop), we can only support the copying protocols; we can't do bridging.  Still,
copying gets you quite far and you can, for instance, call python functions and get
the attribute map from a python object.

Protocol functions implemented:
python-type
->python
->jvm
dir
has-attr?
attr
callable?
has-item?
item
set-item!
do-call-fn
len

Results of these, when they return python pointers, return the raw,unwrapped pointers.
Callers at this level are sitting just close enough to the actual libpy calls to still
get pointers back *but* they don't have to manage the gil.

Protocols to help generalize the python bindings.  There is a clear distinction
made between building a bridging type and thus allowing communication between the
two systems and building a complete copy of the datastructure of one system in
another.  Generic objects must only bridge but if we know more about the object
(like it implements java.util.Map) then we can implement either a bridge or a
copy.

Atomic objects:
* numbers
* booleans
* strings-convertible things like strings, keywords, symbols

Standard containers:
* list
* map
* set
* tuple (persistent vector of length less than 8)