Add a new plugin API. This closes the gap between pass registration and out-of-tree passes for the new PassManager.
Unlike with the existing API, interaction with a plugin is always initiated from the tools perspective. I.e., when a plugin is loaded by the PluginLoader, it resolves and calls a well-known symbol llvmPluginGetInfo to obtain details about the plugin. The fundamental motivation is to get rid of as many global constructors as possible.
The API exposed by the plugin info is kept intentionally minimal.
This seems like a somewhat nasty layering...
If plugins fundamentally deal in pass builders, I wouldn't expect the plugin infrastructure to be in the Support library at all. I think the only reason the plugin stuff started off in the support library is because it relied exclusively on global ctors to connect to any functionality. I really like the idea of moving away from that for plugins and having a more proper callback mechanism, but I think it means we need to either use some abstraction or just make the plugin logic (somewhat) specific to *pass builder* plugins.
Beyond getting the layering and pass build stuff designed nicely, I suspect we should rope some folks more broadly in the community in to make sure the high level approach to plugins here makes sense long term... I'll try to ask around and see who has opinions here.