add DB level propagation for the Unscoped flag

[sprataa]

• Do only one thing
• Non breaking API changes
• Tested

What did this pull request do?

This PR adds PropagateUnscoped to DB's Config. Its purpose is to allow propagation of the parent Statement's Unscoped flag to nested statements.

Should this become the default behavior?

Is there any scenario where getInstance() where we don't want this flag to propagate? For the record, all tests pass if we just persist the Unscoped state when clone == 1.

I just didn't want to introduce what may be a breaking change in more complex production environments for which gorm's tests don't offer coverage therefore this is a disabled by default flag.

Regardless, this kind of change should not be introduced without a flag to panic control it.

User Case Description

When one wants to create advanced hooks which leverage not just the usual Before/After but also StatementModifier hooks while reusing the Unscoped state of the parent statement, it can be expected that the flag propagates to all child hooks.

One can, and that's what we find ourselves doing more often than not, is to store the original tx/stmt's Unscoped state and adding repeated extra lines of code where one wants to keep the state after a nested Delete or Model calls done inside hooks - arguably, in every possibly nested hook.

Since for some, or even all, use cases, one just wants to have Unscoped propagated to all nested statements, this is a way cleaner and non intrusive solution to address such challenge.