Standaloneusers - move canonical role creation from core installer to extension installer

[ufundo]

Overview

This is helpful when migrating from non-Standalone. Currently you have to create these roles manually. This way it can be done during cv en standaloneusers. Also canonise the canonical role names with consts.

Before

• the only way the starting roles were created was when you were installing a fresh civicrm db
• if you already had a civicrm db, and wanted to migrate it to standalone, you had to manually create these somehow

After

• starting roles are created during the Standaloneusers install (which is a step during fresh install, or migration)

Comments

Our starting Roles (admin, staff, everyone) sort of stride the "example data" vs "essential data" line which I think defies a definitive answer to where they should be created:

• everyone has a very special role - we need to know what permissions anonymous users have - it is programmatically essential.
• admin has some controls to prevent it being edited or deleted. I sort of think you might have a site without it (do all the superadmining by CLI, users with logins have less than superadmin permission). It sort of helps possibility of getting locked out from a site, though I don't think it's totally watertight (you can edit users so none has the admin role?)
• staff is basically a useful starting point of how you might want to configure an interim role.

From my perspective everyone should definitely be created in extension install, because you can't log in to your site without it. Given admin is currently canonised, I think it belongs in the same place (I'm less clear it should be canonised, but out of scope).

Staff is less clear. I could be conviced to leave that one in the setup plugin. But it seems simpler to have them in the same place.

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗