Offering to co-maintain Field Defaults

@bobi-mel I am open to it given the direction fits the needs of the module and it's users, as such I'd prefer if you put in issues for features/improvements and MR's to start and I will review and merge.

If things look good, then I will give you co-maintainer. I've had others offer co-maintain before and then do commits without issues, releases without logs/notes, or just abandon, which have ruined modules previously so I exercise caution now. I hope you understand.

One big change this module currently needs is a pluggable system for handling non-normal field types/storage. That has been on my list for a while and I'm hoping to start a roadmap next month. Essentially moving this away from module work and more into OOP with the ability to be much more flexible.

Hi @b_sharpe

I fully understand your concern that I can add changes that might break the module. I propose the following way of our collaboration:
- you can deny me the right to create new releases (we did this for @scott_euser → in the Site Settings and Labels module → );
- I guarantee that I will not add any new changes to the dev branch, only work on issues and do testing;

I think this is the right way to go in this situation.

As for my suggestions for the module development:
- check out my solution for this issue No support for image field 🐛 No support for image field Needs review ;
- in this issue Change Testing to GitLab CI 📌 Change Testing to GitLab CI Needs work to fix phpstan's issue;
- fix issues in test coverage in the issue Fix failing tests for D10.1 📌 Fix failing tests for D10.1 Active ;
- merge these changes into the development branch and start working on your roadmap;

It looks logical to me. If you see another way, we can discuss it.