Preview: remove the Link Manager (Bookmarks) API from core (see #56362)

[georgestephanis]

Related: #56362

This is a preview/reference patch, not proposed for merging as-is. #56362's own rollout plan puts a full removal as the last of five phased steps — after deprecation notices ship in a release and a full cycle passes. Opening this to make that eventual step concrete and grounded in real code, alongside a working standalone plugin that already polyfills everything removed here: https://github.com/georgestephanis/wp-links

That plugin reproduces this functionality under the same function/class names, each guarded with function_exists()/class_exists() (or an equivalent technique where a guard doesn't directly apply — see its README for the specifics), so it activates dormant on a normal install and takes over the moment core stops providing this.

Scope

Matches the companion plugin's current coverage exactly — the API functions/classes, the link_category taxonomy and manage_links capability, the admin pages, the widget, and OPML. Deliberately not touched here, tracked in issue #1 and issue #2 of that repo:

• The wp_links DB table creation in wp-admin/includes/schema.php
• wp-admin/js/link.js / xfn.js and their registrations
• The ~10 already-19-years-deprecated Links functions in wp-includes/deprecated.php (get_linksbyname(), wp_get_links(), etc.) — these call into functions removed here and would fatal if ever invoked; a real patch needs to either remove them too or give them a graceful no-op
• The PHPUnit test suite (tests/phpunit/tests/link*.php, bookmark/*)

Worth flagging from putting this together

• wp-includes/bookmark.php / bookmark-template.php are required unconditionally in wp-settings.php — not guarded the way most of core's Links code is. Deleting the files without also removing those two lines breaks the bootstrap entirely. Only caught by actually booting a build, not by review — see the "How this was verified" note below.
• wp_ajax_add_link_category() and wp_ajax_delete_link() in wp-admin/includes/ajax-actions.php aren't reproduced by the companion plugin (its own known gap), but leaving them in core while removing the functions they call (get_taxonomy('link_category'), get_bookmark(), wp_delete_link()) would leave two guaranteed-fatal AJAX handlers behind, so they're removed here too rather than left dangling.
• A stray wp_list_bookmarks() call in the default theme-compat fallback sidebar (wp-includes/theme-compat/sidebar.php) needed removing as well.

How this was verified

Not just PHP lint — tested against a real WordPress environment (WP Playground) two ways:

1. A normal install boots and runs fine with everything in this diff removed.
2. With the companion plugin active on top of that stripped install: link category creation, link insert/list, front-end wp_list_bookmarks() rendering, and the admin list-table page all work exactly as before, entirely through the plugin's polyfills.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props georgestephanis.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[georgestephanis]

Opened alongside a real, mergeable deprecation-only PR for the intermediate steps of #56362's plan (no behavior change, just notices): #13358

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.