Fix overwriting existing line height style when none has been set in CoBlocks

[p-jackson]

Description

The latest version of Gutenberg includes typography settings which already exist in CoBlocks. This PR doesn't fully harmonise those settings, but it stops CoBlock from disabling the core settings.

Using line-height as an example: if the line height was unset in CoBlocks, then applyStyle() would set the inline style to null. This means that if core Gutenberg had set it's own line height then it would get nulled out. As shown in #1500 this caused the line height to be removed on the front end and could cause invalid block errors.

This PR only sets an inline typography style if one has been set in CoBlocks, otherwise it leaves it alone. This means the CoBlocks setting takes precedent over the core Gutenberg setting on the front end. Maybe it should be the other way round, but this at least fixes the invalid block errors.

It's possible to do this without the _.pickBy function but it's more verbose and I saw this function was already used elsewhere in the plugin. From a code size point of view.

Fixes #1500

Types of changes

Bug fix (non-breaking change which fixes an issue)

How has this been tested?

• Enable latest Gutenberg and disable CoBlocks
• Add a paragraph block to a post
• Set a custom line height in the block settings
• Enable CoBlocks
• Open post, should have no block errors
• Preview post, line height should be applied

And checked the other way round just to be sure

• Enable CoBlocks and disable latest Gutenberg
• Add a paragraph block to a post
• Set a custom line height using the CoBlocks settings in the toolbar
• Enable latest Gutenberg
• Open post, should have no block errors
• Add a different line height using core block settings
• Preview post, line height from CoBlocks settings should be applied

Also tried the above using the other blocks that have custom typograph settings.

Checklist:

• My code is tested
• My code follows accessibility standards
• My code has proper inline documentation

[AnthonyLedesma]

Great work. This resolves the issue reported in #1500 and is good to merge.

[AnthonyLedesma]

Though I approve this PR the work needed for typography controls is not yet completed. A new properly scoped issue details the outstanding required fixes with typography controls.
#1528