Add ColorPicker dialog with checkerboard alpha

[ferdnyc]

So, I was working on generalizing my non-modal QColorDialog changes from the Blender dialog and moving them to the rest of the places where you can select a color in OpenShot, and as I was testing in the Title Editor I realized how unhappy I was with the current functionality, specifically the support for transparency.

A lot of our title templates use transparent backgrounds, which often are colored white (simply because that's the default and nobody changed it). When you go to edit that color in the QColorDialog, well (a) it shows as white, and (b) no matter what color you select, it won't DO anything because it's still set full-transparent.

So, long story short (to avoid burying the lead, but stay tuned for a fuller explanation):

We now have our own color picker, which does support transparency.

I hacked up a modified version of the QColorDialog that monkey-patches itself on opening, so I can replace the original QColorShowLabel widget with its own CPAlphaLabel which paints the selected color over the universal sign for transparency, the gray checkerboard pattern. (Oh, yes, and it also happens to be non-modal, which I think was the original goal. Honestly, I kind of lost track after I got hung up on the whole transparency thing.)

This PR only checks in the ColorPicker implementation, it doesn't use it anywhere. That's for an upcoming PR. But I wanted to get the picker committed first.

The problem

Here's what I mean about the QColorDialog. Here's one of our title templates loaded into the Title Editor:

Go to edit the Background Color, you get this:

Change it to a nice light magenta / electric pink sort of color, you see this:

Click OK, and you end up with this:

Well, that's kind of a letdown. Enter the ColorPicker. Same initial setup, but when it opens you see this:

Change the color, and it changes to this:

It's only when you hike up the alpha channel that the color shows. Here's an alpha of 80 (~31% opaque):

And here's 192 (75% opaque):

Inspired by #3799 (but doesn't yet actually address anything requested there)

[ferdnyc]

There are some down sides to this, though most of them are pre-existing from the QColorDialog:

1. There's no slider for the alpha level. That really suuucks because adjusting it is a chore. You have to either type in the spinbox or use the incredibly laborious "increase" button to slowly move the number up or down.

   You'd think that vertical slider next to the hue map would control transparency but nope, it's just intensity. (AKA "value", the V in HSV.)

2. The HTML field both doesn't show the alpha level, and won't let you enter an alpha value. Again, pre-existing from QColorDialog, the field is limited to 7 characters (including the '#'). QColor() itself understands #aarrggbb strings, but its dialog does not.

3. The label no longer supports drag-and-drop color setting. The original one did, for some reason.
   Not that the CPAlphaLabel couldn't support D&D, it'd just have to be implemented. But that's a non-trivial amount of work and I just didn't do it because, honestly, it feels like the most pointless feature in the world. I can't imagine why anyone would want to drag a color onto the box, when you can select one just by clicking it. So, I didn't bother, and don't plan to unless anyone cares.

4. Using "Pick screen color" (the feature that started all this) always sets the alpha level to 255 (full opacity). That's just how it works, all screen colors are opaque because the screen image is an opaque composite of any transparent layers involved. But other methods of selecting a color, like clicking the swatches in the window, will preserve the selected alpha level, so that's nice.

[ferdnyc]

Merging this, because on its own it doesn't do anything. The changes from #3815 are needed for it to have any effect on the application. This is just to get it in there, in preparation for further PRs.