Separate handling of release candidates

[bmcfee]

As I understand it, we basically have two options for the "default" root version of the docs: master (or some other branch of choice) or the latest (or highest by semver ordering) tag.

This logic doesn't quite work when the latest tag is a pre-release and master is development. For example, I have a project where master is the development version, tag 0.4.3 is the latest stable release, and 0.5.0rc0 is the most recent tag. (I think this is not an uncommon scenario.) In this case, it would be nice to have an option to build docs for release candidates/pre-releases, but keep the default as the highest non-rc tag.

Does this seem reasonable, and would it be difficult to pull off?

(Unrelated: thanks for building this package. It's awesome!)

[Robpol86]

Thanks for the unrelated note :)

This makes sense, I can't believe I didn't realize it sooner since we do something similar at work. It's been a while since I worked on this so I'm not sure how long it'll take me to write a (hopefully) modular solution (maybe let users override the logic by specifying a function in conf.py or something).

It'll probably take a weekend of work by my estimates. I'll try to work on it in a couple of weeks.