Implement the generation of multiple copy constructors for fields

[RazvanN7]

The scheme of copy constructor generation is quite simple:

1. If a copy constructor is defined for any given struct => no copy constructor is generated
2. If a struct does not define a copy constructor but has fields that define copy constructors => define a copy constructor for each unique combination of source-destination qualifiers that is encountered in the fields of the struct.
3. If any of the generated copy constructors fail to typecheck, then they are annotated with disable; as such, copies that are possible are accepted, copies that are not will result in a compiler error.

@WalterBright wanted to implement a strategy where the most restrictive copy constructor is the one that is generated, however, I think that that behavior is very close to the current one where we define an unusable inout(inout) copy constructor. I think my approach is much simpler, since the compiler is let to decide whether the copies are possible or not, however it does probably come with a compile penalty for structs that define lots of copy constructor. However, I suspect that this situation is rare.

[dlang-bot]

Thanks for your pull request and interest in making D better, @RazvanN7! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20876	regression	generated constructor always inout regardless of ability of fields to use inout

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#16429"

[RazvanN7]

Why won't the bot auto-close the issue when this PR is merged? The commit message does contain "Fix Bugzilla Issue 20876"

[thewilsonator]

maybe because the title doesn't start with that? I'm not sure what the exact regex used is

[RazvanN7]

Thanks @thewilsonator , that was it.

[jmdavis]

Thanks. This seems like the right approach and is what I would have expected.

[RazvanN7]

Ok, the headers need to be updated, but apart from that, it seems like the other failures are unrelated.

[PetarKirov]

Suggested change

	result ~= "C";
	result ~= "D";