Cycles Baking, early commit

I squashed the previous commit to undo the rename of bake.c > bake_old.c
This was merge-conflict prone since any change in the bake.c would generate conflict.

(same for object_bake.c)

* More work on getting cycles to have its bake function called.
* Getting through the beast - bake gets called inside Cycles
* I get a crash though, on free_session()
* Get render pass for baking from enum
* Sending the BakePixel and float pointers all the way to Cycles \o/
* Sending some data back just to validate the pipeline going in and out
fix compile error on linux
RE_populate_bake_pixels() - still need work

(see TODO in the function - in bake_new.c)
suppress result printout
RE_populate_bake_pixels working for triangulated faces

I suspect I need to check if the face is 3 or 4 verts,
but for triangles it's working :)
fixing heap corruption bug

by Tom Edwards
bump primitive id and create new face if tessface has 4 vertices
Saving the baked map externally working + more code

How to test it:

bpy.ops.object.bake(type='UV', filepath='/tmp/bake.jpg', width=512,
height=512, is_save_external=True)

The object needs a UV for this to work.

*** Note:

Also we now separate whether we need to use the external baking or not.
Though, now that I think of it, we should probably always use external
when possible, even for UV. Because that's the only map that will make
sense that is in the 'always internal' group (object id and material id
doesn't make a lot of sense as baking options in my opinion).
better to always use the external engine to bake, the only map that
we could map using the internal mechanism is the UV map
remove the spurious prints from Cycles
bakepixels > bake_pixels
cleanup of comments/todo listing in object_bake_new.c