Continue renaming std.traits.*Tuple as per #3264

[ntrel]

Continue renaming of templates resolving to a sequence, but are named as *Tuple.
Some new names don't follow the pattern (shown in italic):

• ParameterIdentifierTuple -> ParameterNames (consistency with FieldNames, shorter)
• ParameterStorageClassTuple -> ParameterStorageClasses
• BaseClassesTuple -> BaseClasses
• BaseTypeTuple -> BaseTypes
• InterfacesTuple -> BaseInterfaces (consistency with above two, interfaces can inherit too)
• FieldNameTuple -> FieldNames
• MemberFunctionsTuple -> MemberOverloads (more precise as it takes a member name argument)
• RepresentationTypeTuple -> RepresentationTypes
• TransitiveBaseTypeTuple -> TransitiveBaseTypes
• isTypeTuple -> isTypes (to match the isExpressionTuple -> isExpressions change)

As #3264 didn't deprecate the legacy aliases, I haven't done so either. BTW that pull did make the following changes, which I think are inaccurate:

• ParameterTypeTuple -> Parameters
• FieldTypeTuple -> Fields

I would prefer those aliases were ParameterTypes and FieldTypes. Mentioning now as it may be a good time to fix those too.

[dlang-bot]

Thanks for your pull request and interest in making D better, @ntrel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[JackStouffer]

This needs a changelog entry.

Also, I'd argue that deprecations should be added onto these aliases. Any objections?

[MetaLang]

They probably weren't deprecated back in 2015 because we weren't as worried about breaking code. I agree with @JackStouffer.

[wilzbach]

Also, I'd argue that deprecations should be added onto these aliases. Any objections?

I tried to revive this too: #4954

Andrei closed it with:

This seems to be a pass that someone made through a personal project after finding a nicer naming convention. I think it breaks too many things for too little benefit.

So yeah, it looks like we can't deprecate the aliases, but imho we should still do the renames.

BTW there was also #4968 which didn't get any interest at that time.

[andralex]

No more grand renamings please.

[JackStouffer]

Well, since Andrei is in charge of names I think it's safe to close this.

[ntrel]

Would this be appropriate for std2?