Development/BrushInstancesRefactoring

Current state

 * One class hierarchy for brushes: mypaintlib.Brush -> lib.brush.Brush -> brushmanager.ManagedBrush
 * Used to represent two different types of brushes: those who are used for painting with and those that are just used to store settings
 * An instance is made for each available brush (300+ by default)
 * Each instance has 30+ instances of a Setting class

Problems:
 * Not very clean, the two types are actually quite different
 * Poor performance on startup due to the creation of all these heavy objects

Requirements
Separation between the two different brush types, called PaintingBrush and SettingsBrush for now.

1. PaintingBrush
Used to paint with, and manipulated using the GUI. Few instances, one per TiledDrawWidget (default: two)
 * Responsibilities: notify observers about change, keep in sync with C implementation,
 * Data: Preview, (file)name, Settings <--- Preview and Name are not required for painting. we could store this only in SettingsBrush.

2. SettingsBrush
Used to manage available brushes. Many instances, up to one per available brush (default: about 300)
 * Data: Preview, (file)name, Settings
 * Responsibilities: Data persistence

3. Settings
How to represent the brush settings?? Should be a primitive object due to the amount of objects involved. Or only PaintingBrushes could have this instantiated.

4. SettingsBrush <-> PaintingBrush

 * Take the brush represented by a SettingsBrush and use it as a PaintingBrush
 * Take the brush represented by a PaintingBrush and persist its data as if was a SettingsBrush

Design Ideas
Cold Storage (SettingsBrush): Hot Storage (PaintingBrush):
 * For the SettingsBrush the existing string representation of the brush could be used
 * Pro: can load the .myb file on demand
 * Con: cannot easily inspect the brushes that are not in use (eg. for searching for a parent brush id later)
 * A two dimensional numpy array could be used.
 * Pro: only one object, compact representation of the actual data
 * Pro: could be passed with a single call to brush.hpp (after modification of the C code)
 * Con: accessing all elements from python might still be slow
 * Con: wasting some memory since most brush settings don't have a mapping
 * Con: somewhat pointless if we only access it from python
 * The current lib.brush.Brush could be used but without the ability to update down to brush.hpp
 * Con: probably still a lot of time wasted in constructing it
 * We could write down the settings into the C brush class (which we have to do anyway), and add getters to read the values back, instead of storing second copy of them in Python.
 * We could leave it as it is (using lib.brush.Brush), as this is not time critical when we only have two instances. We only need to associate the PaintingBrush with the currently selected SettingsBrush for saving the settings back, preview, brush name, etc.