Currently, for extensions which provide a conceptual link between pages, there is no way to add these links into Special:WhatLinksHere.
For example, my WikiDB extension [1] adds database functionality to the wiki, such as table definitions (defined in a custom namespace), <data> tags (which define the data that goes in them) and <repeat> tags (which are, effectively, queries). When viewing 'what links here' for the table definition, users would expect to see included any pages which display the table's data (via a <repeat> tag).
I logged bug T161066 which suggested combining the existing link tables into a single table, which would allow extensions to define new link types and simply add their records to this table. From a coding perspective, this is a very neat solution - extensions would define a link type (e.g. "wikidb_data") and insert records into this table with the appropriate link type set. Once migrated to the new structure, the 'what links here' page would be able to include custom link types in the output with no additional coding, as they would be the same as any other link. It would also be able to automatically add the toggle to show/hide links of this type to the filter options at the top of the page. The only other thing the extension would need to do would be to define some i18n messages (e.g. 'wikidb_data_showlinks', 'wikidb_data_hidelinks', etc.) which MW would be able to locate automatically based on the link type.
The above bug was closed due to concerns over database administration (due to the large size of the combined table) so I'm logging this bug to consider what other approaches could be taken to allow this functionality for extensions.
As far as I can see, this is not something that could easily be handled by a simple hook as there are multiple aspects that would need configuring.
Perhaps it could be implemented via a PHP abstract class, with a child class defined for each link type (including the built-in types, such as images, templates, pages, etc.). All an extension would need to do is register its own similar class and implement the relevant abstract methods.
However, the above are just a couple of suggestions, without having a deep understanding of the practical requirements. Therefore, the first thing to be done in this ticket is for someone a bit more knowledgeable than myself to consider what mechanism we could use to achieve this functionality and what specific complexities may need to be overcome.