feat: introduce AlertButtonWithConfig with variant from config

[adamstankiewicz]

Description:

Introduces a new component, DefaultAlertButton, in the react module. It intends to be used by consuming MFEs in the Alert component's actions prop to ensure that Alert's CTAs can be reasonably configured to rely on a different default Button variant than is used in the upstream MFE code. For example, @edx/elm-theme calls for

However, this approach on its own, does not adequately address how the Paragon docs site itself would adhere to a change in the default Button variant used with Alert when previewing @edx/elm-theme.

To ensure the overridden alert button variant is applied consistently across all MFEs for a given instance, it may be recommended that operators define a common env.config (e.g., env.config.common.js) that is consumed by all MFE-specific env.config files so that MFEs don't need to duplicate the same style overrides in multiple places.

The idea here would be that openedx MFEs that supply actions to the Alert component should begin using DefaultAlertButton from @edx/frontend-platform/react instead so the configured button variant override is applied without any additional effort within the MFE. It should be as simple as replacing <Button> with <DefaultAlertButton> in the appropriate places.

See more details from the Paragon Working Group meeting on 4/2 here.

Next steps:

• Share and refine this proposed approach with 2U/edX.org's internal fedx meeting based on any early feedback.
• Draft an ADR to further document the rationale for this approach and adoption strategy throughout openedx.
  • Formalize the expected config structure within env.config for such style overrides, considering future use cases beyond the immediate Alert.
  • Get PR out of draft and into code review.

Merge checklist:

• Consider running your code modifications in the included example app within frontend-platform. This can be done by running npm start and opening http://localhost:8080.
• Consider testing your code modifications in another local micro-frontend using local aliases configured via the module.config.js file in frontend-build.
• Verify your commit title/body conforms to the conventional commits format (e.g., fix, feat) and is appropriate for your code change. Consider whether your code is a breaking change, and modify your commit accordingly.

Post merge:

• After the build finishes for the merged commit, verify the new release has been pushed to NPM.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 12 lines in your changes missing coverage. Please review.

Project coverage is 86.04%. Comparing base (455c45e) to head (8c19ab5).

Files with missing lines	Patch %	Lines
src/react/paragon/DefaultAlertButton.jsx	0.00%	12 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #789      +/-   ##
==========================================
- Coverage   86.78%   86.04%   -0.74%     
==========================================
  Files          48       49       +1     
  Lines        1400     1412      +12     
  Branches      294      299       +5     
==========================================
  Hits         1215     1215              
- Misses        172      184      +12     
  Partials       13       13              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.