If a module is Not Supported, Drupal's warning links to available updates page, which says everything is OK

Problem/Motivation

Say you're on the modules page and update manager tells you this:

The installed version of at least one of your modules or themes is no longer supported. Upgrading or disabling is strongly recommended. See the project homepage for more details. See the available updates page for more information and to install your missing updates.

The text "available updates" is then linked to admin/reports/updates/update which says:

All of your projects are up to date.

It's necessary to go to admin/reports/updates to see what module and what the issue is:

Project not supported: This project is no longer supported, and is no longer available for download. Disabling everything included by this project is strongly recommended!

Proposed resolution

Include information about unsupported projects on the 'Update' form at /admin/reports/updates/update

2 possible approaches, we must pick one:

Include them in the 'Manual updates required' table

See #25

Downside: 'Recommended version' makes no sense as a column header in this case.

Add a new table for unsupported projects

Along the lines of what we did at #3113992: The 'Update' page has no idea that some updates are incompatible. A separate table might be easier to deal with, we can optimize the column headers to make sense for unsupported projects, etc.

Downside: Adds Yet More Tables(tm) to this page. In a really wonky example, a site might have 5 tables on this page:

1. Normal available updates with checkboxes to update them (the functional part of this UI)
2. Manual updates (core)
3. Unsupported projects (this issue)
4. Incompatible updates #3113992: The 'Update' page has no idea that some updates are incompatible
5. Uninstalled/disabled projects #3117553: Change UI for /admin/reports/updates/update to not mention "Disabled" modules and themes

Not yet implemented, so no screenshot.

Something like:

Unsupported projects

(more or less).

Remaining tasks

1. Decide which approach we want.
2. Implement it.
3. Update/add test coverage.
4. Reviews/refinements.
5. RTBC.
6. Commit.

User interface changes

TBD.

API changes

Probably nothing public.

Data model changes

Nope.

Release notes snippet

TBD.