Fix T38654: Using a non-camera object for the SetCamera Scene Actuator causes a segfault.

Non-camera objects are not supported as cameras, and trying to use them
just causes memory errors (some bad typecasts are involved). When converting
a Scene Actuator, only use the object as a camera if it is actually a camera.
Also, the logic brick UI now filters for camera objects, which should help
avoid confusion.
NDOF: use like a joystick for cube picker (as with circle picker)
NDOF: image and clip views ignored axis invert preferences

also X/Y invert was swapped for 3d view.
NDOF: fix for broken zoom invert for image and clip editor

also match zoom speed with 3d view
NDOF: show invert pan & zoom in the menu outside the 3d view
NDOF: support pan/zoom for view2d (nodes, graph editor, sequencer... etc)
NDOF: add keymapping for the 'fit' button for other 2d views
Fix FCurve reading freed themes, assert to prevent further misuse
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