Recruit with pending conditions status tags

[stevehook]

Context

It would be beneficial to SCITT providers if we allowed them to move a candidate who was only pending SKE conditions to ‘Recruited’ as this would automatically import their record into Register saving them from having to manually create it. This is particularly useful for providers (and DfE) who are busy getting their ITT data ready for the ITT census deadline in October.

We have a PR (#8650) to implement the basics of this feature (mainly the forms in Manage that enable a provider to recruit a candidate despite them having a pending SKE condition). This PR builds upon that work by adding an additional status 'tag' for recruited applications that still have SKE conditions pending so that providers, support and the candidates themselves can all see at a glance that this is the case.

Changes proposed in this pull request

The various ApplicationStatusTagComponent classes all need to be rendered with an additional SKE pending conditions label when the application in question is in the recruited state but has one or more pending SKE conditions.

Manager

Support

Candidate interface

Guidance to review

DRAFT FOR NOW

Link to Trello card

Things to check

• If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
• This code does not rely on migrations in the same Pull Request
• If this code includes a migration adding or changing columns, it also backfills existing records for consistency
• If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
• API release notes have been updated if necessary
• If it adds a significant user-facing change, is it documented in the CHANGELOG?
• Required environment variables have been updated added to the Azure KeyVault

[stevehook]

On second thoughts I reckon the handling of supplementary statuses should probably be handled in the component itself rather than passed in. supplementary_statuses_for should probably be a method on the ApplicationChoice model rather than a helper method. Any thoughts?