Make BB-tracks themeable
- This allows defining a default colour for BB-track patterns in the CSS
- The default colour is used for all bb-patterns which don't have a custom colour set by the user: in other words, the colour of a pattern can be any rgb-value OR "style colour"
- By default, all created bb-patterns use the style colour
- You can also reset colourized patterns to use style colour again
- Backwards compatibility: old projects will be loaded so that any pattern using either of the old default colours will be converted to use style colour

TODO: add a settings option that can disable custom colours (ie. always use style colour), and/or an option to reset all patterns in a project to style colour. This is needed, since themes can now change the song editor background, which can lead to unfortunate colour combinations with custom colours...
Ensure that NotePlayHandles get processed before the InstrumentPlayHandle on instruments that use both NotePlayHandles and InstrumentPlayHandle, such as LB302 and SF2-Player
Issue: Currently, we use threads to process all PlayHandles, so there's no guarantee of the order they are processed in. This causes timing inaccuracy and jitter: notes of instruments that use both NPH's and IPH's can get randomly delayed by one entire period.
The issue is solved thusly:
- When processing an IPH, we check if the instrument is midi-based. If yes, we just process it normally (no NPH's to worry about).
- If it's not, then it also uses NPH's, so we'll have the IPH wait until all NPH's belonging to same instrument have been processed. There's some similar code in the new FX mixer, I pretty much just copied how we do it there.
LB302: Fix playback bugs (sticking pitch), add bandlimited waves
Fix drag/drop for automation patterns
There was some apparently legacy code that was entirely unnecessary and interfering with model drops.
Closes #814
Use QBrush instead of QColor on some theme properties
Apparently, we can use QBrush -typed properties in the CSS. This just never occured to me before!
So, this has several benefits. A QColor property only allows a singular RGB value, but a QBrush allows the same plus also qgradients, RGBA-colours and maybe even bitmap patterns. So I'm changing some properties to QBrush, where it makes sense to allow this additional functionality - no need to enable it for simple things like text colours or such.

- Song editor background: instead of the earlier hack with 7 qproperties just to set a limited background gradient, we can use only 2 properties and allow much more flexibility with Qt's own qgradient syntax
- Automation editor: background, graph colour, and the sidebar colour - @musikBear recently complained not seeing the grid through the graph, so transparency can help there, and qlineargradients in the graph can produce very cool visual effects. Grid is pointless to change, it should stay single-colour for now.
- Piano roll: here, I only made the background use QBrush - we don't really have much else here that can utilize QBrush, the notes have their own gradient system... maybe the 2nd colour of the note gradient could be customizable though.

There are probably more places where this change makes sense...
Merge pull request #825 from diizy/qbrush

Use QBrush instead of QColor on some theme properties
update fr translation
Merge pull request #823 from diizy/automation

Fix drag/drop for automation patterns
Merge pull request #829 from ycollet/update_fr_1.1

Update fr for stable-1.1
Merge pull request #817 from diizy/bbtrack-ui

Make BB-tracks themeable
Merge pull request #820 from diizy/lb302fix

LB302: Fix playback bugs (sticking pitch), add bandlimited waves
Merge pull request #819 from diizy/mixeriph2

Ensure that NotePlayHandles get processed before the InstrumentPlayHandl...
LB302: further fixes
- My earlier fixes caused some new issues, now I'm fixing them, this time I'm pretty sure there won't be anything I missed