Implemented color class mechanism in button.

[jorgefilipecosta]

Description

This PR makes button block use classes for colors that are pre-specified in the palette. No visual changes should be expected.

How has this been tested?

Test the following actions in a theme that does not set the color palette (Gutenberg default is used):

1. Add a button block, change colors of background and or text to colors from the palette.
2. Add a button block, change colors of background and or text to custom colors.
3. Verify in the code view that for the first case classes were used to set the color and in the second case inline styles were used to set the color.
4. Save the post see and see it display correctly on the frontend.

Test the following actions in a theme that sets the color palette in the old mechanism without names and classes:

1. Add a button block, change colors of background and or text to colors from the palette.
2. Add a button block, change colors of background and or text to custom colors.
3. Verify in the code view that for both cases inline styles were used.
4. Save the post see and see it display correctly on the frontend.

[youknowriad]

This works as expected but I admit I have a small issue with the initializeColor prop.

[youknowriad]

This intiailizeColor calls are bothering me a bit. It seems too magic to me. I wonder if it's not better to transform the withColors HoC to something like

withColors( ( getColor, { attributes } ) => ( {
   backgroundColor: getColor( attributes.backgroundColor, attributes.customBackgroundColor, 'background-color' )
} )

[jorgefilipecosta]

Thank you for the review and for the feedback @youknowriad. I like your suggestion, I will give it a try in a separate PR.
Regarding the setters (the logic to set the name attribute or the custom one) do you think we should pass a getColor to retrieve the data and a setColor to build the setter, or getColor returns the setter inside similar to what initiailizeColor does?

[youknowriad]

I'd lean towards a separate setColor