Fix semantics of MEP22 image names.

[anntzer]

See writeup in changelog note. Closes #27400.

@tacaswell I think the behavior here also handles the use case you mention at #27400 (comment).

PR summary

PR checklist

• "closes #0000" is in the body of the PR description to link the related issue
• new and changed code is tested
• Plotting related features are demonstrated in an example
• New Features and API Changes are noted with a directive and release note
• Documentation complies with general and docstring guidelines

[tacaswell]

Seems a bit overkill, but 👍🏻

I think we should always return an absolute path. Minor preference we move to pathlib internally but 🤷🏻 either way.

[anntzer]

Switched to returning an absolute path. Like most people(?) I also prefer pathlib, but the return value immediately gets passed to add_toolitem, which is documented to take a str as input (and is technically something overridable by third-party backends) and I don't really want to bother changing that (especially as the filename will typically then get passed to a gui toolkit code to load the icon, and these typically don't actually support pathlib but plain str paths). So overall in this specific case I'm not convinced it's worth switching to returning a Path that'll immediately get converted back to a str (but I don't feel strongly either way).

[QuLogic]

This will break webagg, which expects an image basename (which is mapped to a FontAwesome icon as a class name), which doesn't appear to be stripped of the new prefix here. It may also affect ipympl.

[anntzer]

I don't think it does? Both backends only implement the classic toolbar2, not mep22 toolmanager.

[QuLogic]

Indeed, you are correct about that. Looks good to me then.

[drmcnelson]

Thank you