Replace Identifiers* names with ArgumentLabels* names across the frontend

[Ay1nDas]

This PR is a continuation of PR #21262. Check it out for more details.

#Summary

This PR replaces all uses of the Identifiers* names field in expression-related functions (callExp, newExp, etc.) with a more expressive and structured alternative: ArgumentLabels* argLabels.

• Replaced all names fields (of type Identifiers*) with argLabels (of type ArgumentLabels* = Array!(ArgumentLabel)).
• Code using argLabels is backwards-compatible where necessary by providing Identifiers* via helper conversion.

[ibuclaw]

This shouldn't be targeting stable unless it's a bug fix. Thanks.

[Ay1nDas]

Apologies for the confusion caused. I forgot to mention this is a continuation of PR #21262, in that PR I added a new struct ArgLabel in dmd/expression.d and implemented it in some places to fix issue #21215.
This PR is to replace Identifiers* names with ArgumentLabels* argLabels (defined here) so that we don't have to maintain 3 different arrays for expressions (arguments, argLabels, names).

Now to answer the questions:

• I modified all the required instances of expandTuples() to accept the new argLabels. You can see the function definition at dmd/expression.d. I think that's why it is passing the tests.
• ArgumentLabel is defined here. ArgLabels is an alias defined here.
• This pr is targeting stable instead of master as the definition for ArgLabel was added in stable after the merge of PR Fix #21215: Wrong location for "not a member" error when constructing a struct literal #21262. Which itself was a bug fix for issue Wrong location for "not a member" error when constructing a struct literal #21215.

I hope this clarifies everything. I split the changes into 2 PRs as I thought it would be confusing and people might think... why all the names are being replaced with argLabels to fix a bug?

[dkorpel]

This PR's diff does 2 things:

• rename names to argLabels
• fix the bug where argLabels don't get expanded with tuples

Mixing refactoring and bug fixes in a single pull requests should generally be avoided, because when a regression happens and a bissection points to this PR, it is still hard to see what's going on because actual code changes are mixed with many lines that simply rename something. Can you simplify this PR by applying the code changes to the original names variable?