Support target-spec json file extension in case-insensitive form

[boozook]

Following rust-lang/rust#127389 to complete it on both sides. Small minor improvement without breaking changes.

Currently user's target json file can have only .json ext, but for file that ends with `.JSON' (in caps).

It could be useful in some old OS and old file-systems such as FAT, for example.

Performance cost:

Approximately no changes.
Comparison using eq_ignore_ascii_case for only latest ext_len chars of the OsStr - using Path::extension with eq_ignore_ascii_case.

Testing

I did not add any new tests for specs, such as with file-extensions like jSoN because minor change and doesn't changes existing behaviour, so existing tests are often. Should I add tests?

Also there is no test because cargo tests requires stable toolchain, but to export host target spec I need nightly, using cmd cargo rustc --bin=cargo --print target-spec-json -Zunstable-options -- -Zunstable-options. Of course, I can hardcode it, but it requires nightly rustc for build-std... 🤔 What I should to do?

How to test:

1. use rustc from Support target-spec json file extension in various cases rust#127389
2. rustc --print target-spec-json -Zunstable-options > ./some-target.JSON
3. remove is-builtin field from the some-target.JSON or set to false
4. cargo build --target=some-target.JSON should work

Implementation note

I've separated the comparison into a trait with methods for use instead of just str.ends_with(".json") and to maintain future compatibility.
The trait is public for the same reasons and for potential future usage, including other dependent crates.

Questions

• Name of the trait HasExtIgnoreCase is a good name?
• The trait probably could be good to place somewhere in crate::util. Or not.

---

This text looks like a copypasta of that PR. That's not exactly so. The changes are similar, and there are noticeable differences in the two texts. I apologize if this has caused inconvenience.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[epage]

Moved to draft as this is dependent on an unreviewed PR in rust-lang/rust for an Issue that hasn't had an MCP.