Introduce WP_Plugin class analogous to WP_Theme

[swissspidy]

Background:

This ticket emerged from #37656.

A WP_Plugin class has been previously mentioned in #22256 and brought up with a patch in #21883, but only in regards of hooks and filters (i.e. $GLOBALS['wp_global_hooks'] = new WP_Plugin();. With #17817 in contention, that approach would need some more tweaking. Also, the class name isn't ideal too because of WP_Theme. Using WP_Plugin for hooks but themes can use hooks too? Confusing.

Proposal:

Introducing a new WP_Plugin class that does similar things as the already existing WP_Theme class but for plugins.

This would mainly mean handling caching, retrieving data from plugin file headers and adding any needed helper methods. As a result, we're less prone to errors since we can use 1 reliable API instead of get_plugin_data(), get_plugins(), etc.

[afragen]

Having an equivalent WP_Plugin class to WP_Theme would be great. Personally, having written code to pull header data from both plugins/themes, it would allow for more reusable code.

[jdgrimes]

Proposal from a comment I left on #37656:

As far as making WP_Plugin hold the plugin header data as WP_Theme does for themes, I have a proposal to make in regard to that. What if instead of having to read the file to parse the plugin headers, the header data was passed directly to a function?

<?php

WP_Plugins::register(
   '
   Plugin Name: Foo
   ...
   '
);

The cool thing is that this will still work with the file parsing, since get_file_data() doesn't specifically look for this information only within PHP comments. But it also allows us to get the raw headers without having to read the files at all. So when the plugin is active, we can parse this string passed directly to our function to get the plugin data, and we can still read it with get_file_data() when the plugin is inactive.

In other words, the main file of the plugin would call this function, in lieu of placing these headers in the opening docblock.