feat(richtext-lexical)!: change link fields handling

[AlessioGr]

Description

BREAKING:

• Drawer fields are no longer wrapped in a fields group. This might be breaking if you depend on them being in a field group in any way - potentially if you use custom link fields. This does not change how the data is saved
• If you pass in an array of custom fields to the link feature, those were previously added to the base fields. Now, they completely replace the base fields for consistency. If you want to ADD fields to the base fields now, you will have to pass in a function and spread defaultFields - similar to how adding your own features to lexical works

Example Migration for ADDING fields to the link base fields:

Previous:

 LinkFeature({
    fields: [
      {
        name: 'rel',
        label: 'Rel Attribute',
        type: 'select',
        hasMany: true,
        options: ['noopener', 'noreferrer', 'nofollow'],
        admin: {
          description:
            'The rel attribute defines the relationship between a linked resource and the current document. This is a custom link field.',
        },
      },
    ],
  }),

Now:

 LinkFeature({
    fields: ({ defaultFields }) => [
      ...defaultFields,
      {
        name: 'rel',
        label: 'Rel Attribute',
        type: 'select',
        hasMany: true,
        options: ['noopener', 'noreferrer', 'nofollow'],
        admin: {
          description:
            'The rel attribute defines the relationship between a linked resource and the current document. This is a custom link field.',
        },
      },
    ],
  }),

This PR also allows the link feature to function even with no fields added. And if you add a label or url field, those are now used as the floating link popup label / link. This allows you to technically use the link feature to save any kind of arbitrary data.

Example:

Once hooks are supported, those label and url fields could be made hidden, virtual fields. Oh the possibilities!

• I have read and understand the CONTRIBUTING.md document in this repository.

Type of change

• Chore (non-breaking change which does not add functionality)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Change to the templates directory (does not affect core functionality)
• Change to the examples directory (does not affect core functionality)
• This change requires a documentation update

Checklist:

• I have added tests that prove my fix is effective or that my feature works
• Existing test suite passes locally with my changes
• I have made corresponding changes to the documentation