Limit brushes to a single paint tool

This patch limits each brush to a single paint tool. It converts Brush.ob_mode to Brush.paint_mode, where paint mode can be: BRUSH_MODE_NONE, BRUSH_MODE_SCULPT, BRUSH_MODE_VERTEX_WEIGHT_PAINT, BRUSH_MODE_TEXTURE_PAINT, or BRUSH_MODE_UV_SCULPT.

During file read, brushes with more than one ob_mode are split in to multiple brushes.

The purpose of this is to simplify brush code. You can now tell which brush tool is in use with just the brush pointer, rather than having to check the current object mode. This would be nice for RNA in particular.

This is a bit rough, wanted to see if there's interest in doing this first (see mail to bf-committers.)

[Jason.A.Wilkins, 2012-02-18 11:16:52]

I did something similar in soc-2011-onion except I did not create a new C
enumeration.  However, I did not go as far as this, mainly because I see us
having a unified paint/sculpt system eventually where brushes can, for example,
both sculpt and texture paint at the same time.  I see the brush->ob_mode as
eventually supporting multiple bit flags even though now it only really supports
1.

One thing about RNA is that it does not have to exactly mirror the underlying C.
 When I re-factored the paint_stroke module I did not create a new stroke
enumeration in C for each possible mode I wanted to show the user in the UI,
instead I created a new RNA enumeration that contained the appropriate
combinations of the already existing bits flags.

In onion if you enable the debug UI code it is possible to change the individual
flags with check boxes and the enumeration drop down box will automatically show
you what I named that combination.  (If you choose an unnamed combination the
box will go blank).

So, if we use your readfile code to split up brushes and only present the user
with a new enumeration that only allows mutually exclusive modes then we can
assume that brush->ob_mode only contains a valid value.

Well, not completely, somebody could put all the brush.use_paint_* in the UI and
check them all like they can now, but we could just write functions like
brush.is_direction_capable() to always fail in that case.

Maybe this is a lot of words just to say: Why do we need a new C enumeration?

[nicholasbishop, 2012-02-19 17:47:41]

Revert to brush to using ob_mode mode field and flags

[nicholasbishop, 2012-02-19 17:53:53]

Fair point, uploaded a new patch that removes the new field and goes back to the
object mode enum.

The point of using a new C enumeration was really just to make clear that it's
choosing between brush tools (Brush.sculpt_tool, Brush.vertextool,
Brush.imagepaint_tool), but that's a bit weak anyway since UV Sculpt doesn't
have a brush tool field.

A couple other changes as well: removed the brush_paint_mode from struct Paint,
was really only used in one place and easily replaced.

Also changed paint_init to not require the brush type by not creating a default
brush if none exists. This situation would only normally come up when creating a
new Scene anyways, at which point the normal brush selection UI is probably more
useful than creating a new generic brush from scratch.