Use identifiers on modal triggers and modal component instead of integral trigger

[TwistMeister]

Use identifiers on modal triggers and modal component, instead of having the trigger as integral part of the modal component.

Changes

Removed the trigger slot and added some logic to assign identifiers to both triggers and modals. This way we are free to place our triggers and modals separately, providing more flexibility when implementing. Needed for #3379, for example.

Issue link

Enabler for #3379

Demo

N/a: the changes aren't visible.

QA notes

Verify that implementing the component in a HTML template by following the README will result in a working trigger-modal pair

---

Code Checklist

• All the commits in this PR are properly PGP-signed and verified.
• This PR only contains functionality relevant to the issue.
• I have written unit tests for the changes or fixes I made.
• I have checked the documentation and made changes where necessary.
• I have performed a self-review of my code and refactored it to the best of my abilities.

• Tickets have been created for newly discovered issues.
• For any non-trivial functionality, I have added integration and/or end-to-end tests.
• I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
• I have included comments in the code to elaborate on what is not self-evident from the code itself, including references to issues and discussions online, or implicit behavior of an interface.

---

Checklist for code reviewers:

Copy-paste the checklist from the docs/source/templates folder into your comment.

---

Checklist for QA:

Copy-paste the checklist from the docs/source/templates folder into your comment.

[ammar92]

Looks good to me, don't have much to add 👍

[ppvg]

Re: making the dialog generic: it's currently responsible for managing form elements that are rendered inside of it. It might be better to leave that responsibility to the content itself, e.g. the JS for a specific form, e.g. via some sort of onDialogClose handler.

[TwistMeister]

FYI: Marked as "Draft" because the current implementation on the plugin tile still needs refactoring.

[ppvg]

Stray console.log but other than that LGTM!

[stephanie0x00]

Checklist for QA:

• I have checked out this branch, and successfully ran a fresh make reset.
• I confirmed that there are no unintended functional regressions in this branch:
  • I have managed to pass the onboarding flow
  • Objects and Findings are created properly
  • Tasks are created and completed properly
• I confirmed that the PR's advertised feature or hotfix works as intended.
• I checked the logs for errors and/or warnings and made issues where necessary

What works:

There do not appear to be any unexpected side effects. Can be merged.

What doesn't work:

n/a

Bug or feature?:

n/a