Easier ntegration with existing TinyTeX installs

[abravalheri]

First of all, thank you very much for maintaining this very useful project!

I like the philosophy behind TinyTeX, and the Python wrapper you guys put together is very convenient (Python is almost ubiquitous nowadays and per-installed on Linux and other POSIX OSs, so it's very easy to get started and lightweight — a great alternative for people who don't use R).

Recently, I tried to use it on a new computer and stumbled on #43, so I decided to read through the code a bit and play with ways of making PyTinyTeX work together with TinyTeX installations made independently of PyTinyTeX. I thought some convenience machinery would be nice, which motivated me to share this PR (others may find it useful too).

Please let me know if you'd consider these additions, or if you have any thoughts.

(Possibly this should be stacked after #45).

[JessicaTegner]

@abravalheri Thanks for putting this together. Nice to see you around. I'd be happy to have PyTinyTeX find existing installations, and --tinytex is a useful addition.

There are two things I'd like fixed before merging:

1. pytinytex --tinytex /some/install uninstall ignores the selected installation. The uninstall branch still passes only args.path, so in a fresh process it targets ~/.pytinytex. We should either honor --tinytex here or reject that combination. Silently removing a different installation is a problem.

2. Automatic discovery stops if an earlier candidate has the wrong architecture. For example, an old x86 installation in ~/.pytinytex prevents an ARM machine from finding a working ARM installation in ~/.TinyTeX. Could we continue checking the remaining candidates during automatic discovery? An incompatible path explicitly supplied by the user should still raise an error.

Please add a regression test for each case, with deletion mocked for the uninstall test.

One other thing I noticed: the cache takes precedence over get_tinytex_path(base=...), so an explicit path is ignored once another installation has been resolved. That predates this PR and doesn’t need to block it, but the new precedence test clears the cache first and therefore misses that case.

Lastly, if you haven't seen it, or maybe you came from it, I'm also the maintainer ofpypandoc which you might also find useful.

[abravalheri]

Thank you very much for taking the time to look at this, @JessicaTegner.
I have put together additional commits to address your review.

I made heavier changes to the function that handles the discovery than the initial version of the submitted PR.
For example, the latest version replaces recursion with a queue and uses an issues accumulated.
The reason behind this is because I wanted to avoid adding more levels of nesting and branching... I hope that is OK.

I also have used logger.warning to tell the user about existing mismatches if a usable version is found, but please let me know if you would prefer warnings.warn.

---

Thank you very much for sharing pypandoc.
It looks like a great project and pairs very nicely with pytinytex.
Lately I have been moving most of my projects over to pytinytex, so I will also have a look on pypandoc so that the integration is smooth.