v0.14.2 patch release, removing RTD PDF build

[argerlt]

I plan on leaving this open for a bit as additional potential downstream pipeline problems are reported, but this includes optional solutions to address #611, #613, and #616

1) (optional) make Arrow3D a public facing class (removed, based on discussion in kikuchipy)
2) Remove the pdf build in ReadtheDocs
3) remove dependency on pycifrw and version restriction from pytest-rerunfailures, as the bugs necessitating both have been patched.

For reviewers

• The PR title is short, concise, and will make sense 1 year later.
• New functions are imported in corresponding __init__.py.
• New features, API changes, and deprecations are mentioned in the unreleased
  section in CHANGELOG.rst.
• Contributor(s) are listed correctly in __credits__ in orix/__init__.py and in
  .zenodo.json.

[argerlt]

@hakonanes, once the current kikuchipy patch 0.11.4 is done, assuming nothing new breaks in orix/pyxem/hyperspy/kikuchipy, this patch is probably good to go.

[hakonanes]

Now that we don't build the PDF, we should remove the nbsphinx prolog specifically for the PDF build:

orix/doc/conf.py

Lines 181 to 185 in 3db9eb7

	.. raw:: latex
	\nbsphinxstartnotebook{\scriptsize\noindent\strut
	\textcolor{gray}{The following section was generated from
	\sphinxcode{\sphinxupquote{\strut {{ docname | escape_latex }}}} \dotfill}}

[hakonanes]

I'm OK with leaving out the PDF. Thanks for making the change!

[hakonanes]

once the current kikuchipy patch 0.11.4 is done [...] this patch is probably good to go

Why do we have to wait kikuchipy? I suggest we finish this and release.

[argerlt]

Just an overabundance of caution, patches are moderately time consuming and I don't want to turn around and have to discuss patch 0.14.3 next week because an oversight broke kikuchipy or hyperspy.

The comment is less relevant though now that pyxem/kikuchipy#772 is showing all green lights. This can probably be merged ASAP.

[hakonanes]

Just an overabundance of caution, patches are moderately time consuming and I don't want to turn around and have to discuss patch 0.14.3 next week [...]

Valid point. To reduce the chance of this happening, we can start by releasing a release candidate (RC) prior releasing an actual release. The process would be:

1. Release an RC to PyPI with version MAJOR.MINOR.PATCHrc1, say, 0.15.0rc1
2. Ask dependents to run their test suit against the RC, e.g. with in a dedicated action where we explicitly install the most recent RS using pip install --pre orix (https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-pre)

I consider this approach a more light-weight version of what @ericpre is doing with HyperSpy, where the test suite of dependents in the ecosystem (exspy, pyxem, kikuchipy, etc.) are run quite frequently when making changes in HS.

[hakonanes]

Thanks for making the changes! Need to fix the date in the changelog, otherwise good!