std.traits.ParameterIdentifierTuple producing empty results.

[Carl Sturtivant]

In the new world of ImportC giving direct access to C in D 2.108, 
and function pointer types and function types being imported into 
D source automatically from the D compilation of C headers, there 
is a case to be made for a maximum of information about the 
declarations in those headers being made available to D. 
Specifically the parameter names in declarations of functions 
(and function pointers) in such headers.

Right now, given a function's signature, 
[`std.traits.ParameterIdentifierTuple`](https://dlang.org/phobos/std_traits.html#ParameterIdentifierTuple) produces the names of its parameters at compile time.
```D
int foo(int num, string name, int);
static assert([ParameterIdentifierTuple!foo] == ["num", "name", 
""]);
```
However, there is no way (so far as I have been able to 
ascertain) to extend this behavior to some frequently occurring 
other ways function names may be associated with signatures in C 
header files.

A common example is a Vtable defined in a C header file, being 
the C representation of an OOP-something defined for C++. When 
compiled with ImportC, as `__cplusplus` is not `#define`d, this 
is what D gets made available automatically.

In effect this is a struct with the field names being the names 
of function pointers each of which is given a signature that 
contains parameter names. In effect the signatures of several 
functions are given whose names are the names of the struct's 
fields.

In this situation, right now ImportC does indeed preserve the 
names of the parameters, just as it does for the vanilla function 
foo above. But as the names are struct field names, there is no 
name that is the name in a signature, and 
`ParameterIdentifierTuple` has no function name to be applied to, 
making the parameter names inaccessible.

How was I able to say that ImportC preserves those names? It is 
still possible to get the *type* of the function pointed to by a 
struct field and see it using `pragma(msg,_)` and the parameter 
names are present: good news, for those of us trying to get the 
parameter names from a signature as a practical matter.  However, 
applying `ParameterIdentifierTuple` to a function *type* (or a 
function pointer type too) produces no names, despite the above 
indicating they are recorded in the type.

Parameter names and their connection to the D types of function 
pointers and functions is a vexed question. On the one hand, 
parameter names do not affect type equality, so a purist may 
argue they should not be a part of the type. The force of this is 
blunted somewhat by the fact that we may simply *define* type 
equality to ignore parameter names. Yet the parameter names 
indicate something about the source of the function type 
definition that is in this sense not a part of the type. This is 
ugly.

As a practical matter right now, it would be good if parameter 
names continue to be stored in the type of a function or function 
pointer, as this is (so far as I have been able to ascertain) the 
only way they are accessible in D. Right now I am extracting them 
using CTFE!

Again, as a practical matter, it would be good if he purist view 
of function and function pointer types could be put aside and 
`ParameterIdentifierTuple` be permitted to work on function and 
function pointer types, at least until there is an alternative 
way for compile-time retrieval of parameter names from ImportC. 
Is there an operational downside to this?

What could an alternative way to get parameter names from ImportC 
be? Either existent now, or a language addition?