Allow versioning of packages published to 'private PyPI'

### 📝 Description of the feature

We can selectively publish builds to an internal PyPI mirror, but these use the package version checked into the repo. As a result, if we want to publish multiple pre-release builds we have to bump the version in git, which results in a lot of unnecessary history noise and changelog entries.

Instead, we should think of some way of allowing multiple versions of the same 'publish version' to be made to PyPI.

My initial thoughts:

> Use the GitHub action run number when pushing these dev builds to the internal PyPI mirror.
>
> Once the GitHub action has cloned the repo, if we’re not building from a tag we should use `poetry version` to append the dev version number to the existing version, resulting in a version number of the form MAJ.MIN.PATCH.devBUILD_NUMBER. We can then be certain that however we publish the wheel, it will always have a unique version number.
>
> We have done something cleverer in the past, by increments a version number stored in a orphaned git branch, explicitly for every build. However, this was done because the dev build number and the ‘release’ build number were the same, and so we just removed the dev prefix when we build from a release branch. This isn’t the PyAnsys approach though. Doing this is a lot of extra overhead, and a lot of extra committing as part of CI, which always causes awkwardness.

### 💡 Steps for implementing the feature

_No response_

### 🔗 Useful links and references

_No response_

Start by locating the GitHub Actions workflow that publishes builds to the private PyPI mirror and reviewing how Poetry obtains the package version. Compare the proposed run-number-based dev suffix with tagged builds; done means multiple untagged builds can publish unique versions without changing the checked-in release version.

Written by the indexing model from the issue text.