Support Flickwerk-style patches

[mamhoff]

This enables using patches (i.e. "decorators"/"overrides") in Solidus engines, but using the style described in the Flickwerk README.

In short, this allows autoloading patches whenever the file being patches is loaded by Zeitwerk.

The new directory to put your patches into would be app/patches, and the files inside should be named my_extension/spree_user_patch.rb and define a constant MyExtension::SpreeUserPatch. The convention is that the module prepends itself to the class being patched, in this example Spree::User.

The following are mandatory for all PRs:

• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[jarednorman]

This looks great. I love how the work you've done on flickwerk makes this change so simple.

[tvdeyen]

Nice werk.

[kennyadsl]

Looks promising! We did something similar in the past, with Prependers but it never took off (p.s. I'd like your opinion on the different approach used there, but in the past Zeitwerk wasn't as complete as today).

By the way, I'd like to explore a couple of things:

1. What's the migration plan? I'd like to get rid of the old way of "decorating" classes, if we establish a new convention using this pattern. I guess people decorated gem's code into the decorator folder now. Should we also introduce a deprecation warning, or a message that asks people to move to the new pattern?
2. Having this gem as a strong dependency on our ecosystem doesn't make me feel ok. For example, some of us have permissions on Deface, just in case some changes there are needed by the core team. What would the governance be here?

Thanks again for the stellar work as always.

[mamhoff]

1. I'm writing a script that allows migrating easily. We can introduce the pattern first and deprecate the other one later, when we've at least migrated the most important gems in the ecosystem, otherwise it'll just be raining deprecation warnings. Then we can totally add something that warns if there are any files in decorators.
2. I can give Thomas permissions, but also: The amount of code in Flickwerk is quite minimal, and it's published with an MIT license. If you find yourself in a spot where you need to ditch the dependency, just fork/copy/whatever.

[mamhoff]

Honestly, I looked at prependers and didn't quite "get" it. The inspiration for this work came from a closed PR on this Repo, and I looked for ways to getting the best feature from that and implementing it in a way that is so simple people wouldn't be afraid to use it.

[mamhoff]

Script is here: friendlycart/flickwerk#2