Deprecate the "guidelines" field in favor of description

IDK what is going on with GitLab right now, but I cannot create a merge request for this.

Here is a patch.

I'm not even sure we want to do this.

I find that the description and the guidelines have different purposes, even if there is some overlap.
I'd expect the description to be a shorter version of the guidelines, and having the guidelines provide more detailed info, which might includes e.g. links.

Additionally, description config schema is text. while we are wanting to use html there (see ✨ Guidelines can have html, so fix the config schema Active which will add the datatypes).
Users will be confused if they use an "advanced" text format and Xss::filter strips out their html. We should use the text_format render element instead of #markup.

I have seen confusion by devs using DMG after the description field came available. They have been filling both fields with the same information.

IMO having both is confusing, and training them on what to put where seems the solution to poor UX.

What do you suggest to address this confusion?

Re #2, I created the MR for you: https://git.drupalcode.org/project/dmg/-/merge_requests/8

Not sure how you were doing it, but the fact that I could makes me thing that you were not logged in gitlab. Also, when there is no MR created, there is a "compare" link next to the branch name that would take you to the compare screen, where a "Create merge request" button appears (again, only if logged in and if you have access to the fork).

Not sure for Mateu, for me the reason was definitely "have access to the fork". Thanks Fran!

@e0ipso Assuming I agree with you (no, you didn't convince me yet), how would you handle the upgrade path? You can't override the description with the existing guidelines if they have different values or they aren't empty.

Also, when html or html_fragment datatype lands, you would need to implement hook_config_schema_info_alter, which looks less than ideal to me.

If I were to start this module from scratch, I wouldn't mind that much, even I still think they serve different purposes. But given people might have already data in both fields, I don't think we can do this at this point.