Extended UILayout for node drawing

This patch extends the draw_buttons function of nodes to integrate sockets into the general layout system and allow more flexible placement.

Examples:
  Custom layout (using quick pynodes prototyping):
  http://www.pasteall.org/pic/60728
  Avoiding "staircase" nodes by putting equivalent input/output on same row:
  http://www.pasteall.org/pic/show.php?id=60729

UINodeLayout is a slightly extended variant of the usual UILayout type. It has an additional function "node_socket", which creates a (column) sublayout and draws an input/output socket connector on the node in the vertical middle of the layout.

Using the new layout is optional: any socket that is not handled in draw_buttons is drawn as before in the standard outputs/preview/buttons/inputs order (from top to bottom).

Later this layout system could be used for more advanced features, like:
* Vertical node layouts, placing sockets on the top/bottom node border.
* Automatic disabling of sockets which are not drawn, removing the need for extra update functions.

The uiLayout struct is currently internal to interface_layout.c. In order to access the node pointer in the layout context and allow sockets to retrieve placement info it is necessary to make these accessible in interface_node_layout.c. The layout C structs have therefore been moved into their own header file, intended only for layout implementation.

To read the geometry of a layout after resolving but before freeing block layouts, the uiBlockLayoutResolve function now has 2 parts (only for internal layout use).

Original git branch:
https://www.gitorious.org/blender-trunk/blender-trunk/source/ba27b357bdb0f442d042b841f56cb7e8dec26a73:

[lukas.toenne1, 2013-10-14 14:57:56]

Moved node_layout.c into interface folder to avoid bad level includes

[lukas.toenne1, 2013-10-14 15:09:29]

Avoid bad-level node_intern.h include by moving stuff into the ED_node.h

[brechtvl, 2013-10-14 16:36:44]

I did not look into the code, but I have some doubts about this. If we start
customizing these node layouts, it seems to become more difficult to have
different types of node drawing like vertical, or tree style drawing like in the
material editor, or more compact nodes that do not include so many buttons.
Rather than having generic code, all these variations now have to be taken into
account in such draw_buttons callbacks?

Maybe there's a good use case for this but I don't understand it well, can you
explain why this is needed?

[b.mont29, 2013-10-14 16:53:38]

Made a very quick review… Only a few details spotted, did not have time to
really check all that new code.

https://codereview.appspot.com/14433064/diff/16001/source/blender/editors/inc...
File source/blender/editors/include/ED_node.h (right):

https://codereview.appspot.com/14433064/diff/16001/source/blender/editors/inc...
source/blender/editors/include/ED_node.h:48: struct uiLayout;
Guess uiLayout is no more needed here?

https://codereview.appspot.com/14433064/diff/16001/source/blender/editors/spa...
File source/blender/editors/space_node/node_intern.h (right):

https://codereview.appspot.com/14433064/diff/16001/source/blender/editors/spa...
source/blender/editors/space_node/node_intern.h:52: struct uiLayout;
Same remark here, think uiLayout is no more needed here. ;)