Initial integration of abstract rendering

Abstract rendering framework integration working for count-based analysis.  Includes slots for aggregator, info, chains of shaders and a few basic shaders. 

Notes: 
* Requires separate installation of abstract rendering, but it prints an error if the import fails, including instructions for how to download/install from the main AR repo
* Axis ticks are wrong...just plain wrong.  Don't trust them when using AR.
* Merged in master at 2:46am on 13Jun2013.


Run examples/plotting/server/abstractrender.py yields....
![ar](https://cloud.githubusercontent.com/assets/2963989/3267190/51361f2e-f2c6-11e3-80b3-66f5833868a5.png)

I admit blindly (and apparently incorrectly) copying the existing code.

For AR, it would be nice to be able to send the models over at use-time.
 This would let developers implement and use their own AR functions without
needing to modify the bokehjs install.  I have no idea if its possible.  To
accompany use-time models, a tool to auto-gen the js code based on
properties would be great.   Then I wouldn't have to have an AR core
implementation, proxy object and js model object.  The proxy object can
provide a bare-bones js model, and if a more complex js model is desired,
the implementation can reside near its associated proxy.




On Fri, Jun 13, 2014 at 10:24 AM, Bryan Van de Ven <notifications@github.com
> wrote:

> In bokehjs/src/coffee/common/base.coffee:
>
> > @@ -168,6 +175,12 @@ define [
> >      Tabs:                     'widget/tabs'
> >      Dialog:                   'widget/dialog'
> >
> > +    Cuberoot:                 'transforms/cuberoot'
> > +    Seq:                      'transforms/seq'
> > +    Interpolate:              'transforms/const'
> > +    Const:                    'transforms/interpolate'
> > +    Count:                    'transforms/count'
> > +    Id:                       'transforms/id'
>
> So I wrote this when I knew even less about require than I do now. The
> point was to include everything in one place, because that seemed to be
> necessary for things to work in the fully concatenated file. Basically none
> of the requires for Collections worked if there were not done in one
> place in base.coffee. I would love to make this better if you have
> suggestions.
>
> I will say that even if we need to do all the requires here in base.coffee,
> that does not mean we can't use different names. Collections is basically
> an implementation detail, it's fine to rename the keys (e.g., TransformId
> instead of just Id)
>
> If you have a better general strategy for this that avoids this business
> altogether I would be happy to look into.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/ContinuumIO/bokeh/pull/707/files#r13752285>.
>