BlockStyle typings incorrectly mark some properties as required

[stclairdaniel]

Typings here are as follows:

    interface BlockStyle {
        colourPrimary: string;
        colourSecondary: string;
        colourTertiary: string;
        hat: string
    }

but should be

    interface BlockStyle {
        colourPrimary: string;
        colourSecondary?: string;
        colourTertiary?: string;
        hat?: string
    }

to match docs here

[maribethb]

I believe this is somewhat intentional, based on e.g. https://github.com/google/blockly/blob/master/core/renderers/common/constants.js#L720

The places where BlockStyle is consumed (e.g. in a renderer) need all three of those values, they just don't need to be provided by the developer. However, it appears that in some places we do reference the BlockStyle type in a place where it would make sense to allow undefined values, e.g. in the Blockly.Theme constructor. I think with Blockly.Theme.defineTheme just accepting an Object as parameter, we're losing some type information that allows this situation to occur. It does look like this area could use some type cleanup, but I'm not sure the solution is to just make those properties optional. We might want separate types for the input vs the output after validation, or just stop using the Theme type before validation. Thanks for flagging this!

[BeksOmega]

Related to #6423, importantly #6423 (comment)