Security policy wildcard support for methods/properties

[YSaxon]

Allows for flexible wildcard support in allowedMethods and allowedProperties in SecurityPolicy.

• Class can be specified as wildcard, * => ['foo',...] in order to allow those methods/properties for all classes.
• Method/property can be specified as wildcard eg. \Foo\Bar\Baz => '*' in order to allow all methods/properties for that class.
• Method/property can also be specified with a trailing wildcard to allow all methods/properties with a certain prefix, eg. \Foo\Bar\Baz => ['get*', ...] in order to allow all Baz methods/properties that start with get.

Here are some real examples of security policy items that previously had to be hardcoded that can now be expressed with wildcards:

• Twig's hardcoded security exceptions for methods in Template and Markup classes can be expressed as

'Twig\Template' => '*',
'Twig\Markup' => '*'

• Drupal's $allowed_classes can now be expressed as

Drupal\Core\Template\Attribute => '*'

• Drupal's $allowed_methods and $allowed_prefixes can be expressed together as

'*' => ['get*', 'has*', 'is*', '__toString', 'toString', 'id', 'label', 'bundle']

[fabpot]

I forgot to mention that overall I'm not sold yet this is something I want in core. I very much prefer white-listing explicitly what is allowed. With *, future methods/properties/classes will be automatically "accepted", which can be problematic.

[fabpot]

Or maybe that's fine but we need to make it very clear in the docs that this should be used with caution (can you some docs for this new feature?).