ci: Always run full Jest specs after approval

What does this MR do and why?

Previously, selective Jest jobs ran before and after approvals, with pipeline:run-all-jest label available to override for running full Jest jobs. However, some of recent master broken issues indicate that selective Jest jobs have some test gap, which have been identified when only selective Jest jobs ran and full Jest jobs ran in master.

We should consider running full Jest jobs after approvals until this test gap is identified and addressed.

This MR introduces changes to:

• Run jest full job after the MR is approved instead of jest minimal in MR pipelines.
• Run jest as-if-foss job after the MR is approved and the MR has frontend-patterns-for-as-if-foss changes.

Closes #379174 (closed)

This conceptually reverts !97552 (merged)

Testing

Tested this CI configuration changes in !103559 (closed).

Code changes	Which changes pattern is satisfied?	Approved?	Result
config/routes/admin.rb	code-backstage-patterns	Yes	✅ jest and jest-integration are created: https://gitlab.com/gitlab-org/gitlab/-/pipelines/694458216
config/routes/admin.rb	code-backstage-patterns	No	✅ jest minmal and jest integration are created: https://gitlab.com/gitlab-org/gitlab/-/pipelines/694455982
config/helpers/is_ee_env.js	frontend-patterns-for-as-if-foss	Yes	✅ jest, jest integration, and jest as-if-foss are created: https://gitlab.com/gitlab-org/gitlab/-/pipelines/694436650

I've tested these scenarios by applying ~"pipeline:run-full-rspec" label to the test MR to simulate the pipeline is approved, since if-merge-request-approved condition checks if the MR has ~"pipeline:run-full-rspec" set.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.