Improve meta tag form to clearly distinguish between overriding or reverting the default value (D9)

Hey Folks,

Love what this patch is proposing. Thankfully, the site I'm working with doesn't have a huge array of metatags, so performance is good. One little thing I noticed though was a JS bug throwing in my browser around certain metatag field labels vs naming which would cause the checkbox mechanism to fail:

['metatag-' . $this->name() . '-override']

The line above could resolve to a naming convention that looks like this: metatag-profile:first_name-overrider which as we all know is not a proper JS identifier. So, the front end would throw and error on the first instance of this and fail from that point on.

I believe the fix is to use the id of the tag rather then its name. This patch attempts to solve this issue.

I know mostly this has moved development to version 2.x of the module and that this will likely not get any attention for a while, but I did run into some interesting problems with the Override / Form elements when saving my nodes with the patches in #14 and #27. Basically, when generating the output, tons of failures started happening as the override checkbox was getting involved in the processing.

While tracking through it I also noticed it was really hard to extend tags with extra field attributes unless using hook_attachment_alter() which I was not keen on doing for the large number of mods I was putting into place.

Because of the necessity to manipulate tags in a more "Front End" centric way, I looked to modify how metatag's processTagValue() method worked. Instead of having it placed against the MetatagManager, I moved it into the Tag plug MetaNameBase. This allowed for more leveraging of processing via the Tag themselves. As well, it had a bonus affect of allowing some configuration components to flow into the tags so I could do some more complicated computations with them.

The patch I am submitting is more of a working solution for getting these things factored in a more flexible way. I'm happy to discuss better approaches to anything I've suggested. I'm hoping this leads to a more robust version 2.x

In the interest of better separation of concerns, I'm going to break out the changes in my patch #28 into another ticket. The combination of this and the override was leading down some rabbit holes.

This could be worked on again.