Set Enable Patching to true

[NickDickinsonWilde]

This PR probably does want some thought beyond bug fix... lets merge. This adds 'enable-patching' = true to the extras key. This means that patches from projects will be applied. This is obviously great in many ways but it is a significant change.
Example of usage: https://drupal.org/project/field_states_ui is applying a patch to core so as to be able to use a hook that doesn't exist, without killing kittens.

[jrearick]

This proved to be very useful for being able to add installation profiles that require core patches. Adding it to my configuration seems to have worked very well. I think that if we find incompatible patches in the future, it is possible to add skip patches configuration on a case by case basis https://github.com/cweagans/composer-patches#ignoring-patches.

[jcnventura]

I think this simple change should be merged. It makes a lot of sense to allow patches from included composer.json files. If the patch doesn't apply, composer recovers gracefully and ignores it.

[lhridley]

+1 on adding this

[mxr576]

+1

[AlexSkrypnyk]

This is still relevant for 10.x and 11.x.

Would need to update accordingly using separate PRs.

[leymannx]

Yes, this is very good.

[AlexSkrypnyk]

From https://github.com/cweagans/composer-patches/tree/1.x

If your project doesn't supply any patches of its own, but you still want to accept patches from dependencies, you must have the following in your composer file: ...

Enabling this option adds a new attack vector. I think we should not be promoting this workflow. If patches are needed - the consumer project (project started from this template) should explicitly list them in own composer.json file to have full control of what code is being added.

People using this project in their automated tooling and requiring this option should be adding it themselves, realising that they are taking full responsibility for this workflow.

[leymannx]

Green from me, but we need to resolve conflicts and composer normalize.

[AlexSkrypnyk]

@leymannx
Could you please address the concerns in my comment

[leymannx]

@AlexSkrypnyk – I only work in projects where this always on. That said, this template here will always install without it set, so we might just skip it. People requiring sub-packages with their own patches probably know what they do and we could leave it to them to set it themselves.

[leymannx]

Locking also at how few comments it got in almost 10 years, I tend to leave it out, yes.

[AlexSkrypnyk]

Closing as won't do.

Consumer projects should add this setting explicitly in their composer.json.