Upgrade Sphinx version used in doc deployment (#735)

* Upgrade Sphinx version used in doc deployment

It was breaking with:
```
sphinx-build "spec/2021.12" "_site/2021.12" -W --keep-going
Running Sphinx v4.3.0

Sphinx version error:
The sphinxcontrib.applehelp extension used by this project needs at least Sphinx v5.0; it therefore cannot be built with this version.
```

* Fix some doc build warnings that broke in CI

Author: rgommers

doc-requirements.txt

@@ -1,8 +1,7 @@
-sphinx==4.3.0
+sphinx==6.2.1
 sphinx-material==0.0.30
 myst-parser
 sphinx_markdown_tables
 sphinx_copybutton
 sphinx_favicon
-docutils<0.18
 sphinx-math-dollar

spec/2021.12/assumptions.md

@@ -26,7 +26,7 @@ of functions to be predictable from input dtypes only rather than input values.
 
 The only dependency that's assumed in this standard is that on Python itself.
 Python >= 3.8 is assumed, motivated by the use of positional-only parameters
-(see [function and method signatures](API_specification/function_and_method_signatures.md)).
+(see [function and method signatures](API_specification/function_and_method_signatures.rst)).
 
 Importantly, array libraries are not assumed to be aware of each other, or of
 a common array-specific layer. The [use cases](use_cases.md) do not require
@@ -39,7 +39,7 @@ for that is:
 
 Array libraries may know how to interoperate with each other, for example by
 constructing their own array type from that of another library or by shared
-memory use of an array (see [Data interchange mechanisms](design_topics/data_interchange.md)).
+memory use of an array (see [Data interchange mechanisms](design_topics/data_interchange.rst)).
 This can be done without a dependency though - only adherence to a protocol is
 enough.
 

spec/2021.12/purpose_and_scope.md

@@ -151,7 +151,7 @@ standard is shown in this diagram:
    _Rationale: this is an important topic for some array-consuming libraries,
    but there is no widely shared C/Cython API and hence it doesn't make sense at
    this point in time to standardize anything. See
-   the [C API section](design_topics/C_API.md) for more details._
+   the [C API section](design_topics/C_API.rst) for more details._
 
 4. Standardization of these dtypes is out of scope: bfloat16, complex, extended
    precision floating point, datetime, string, object and void dtypes.

spec/2021.12/use_cases.md

@@ -59,7 +59,7 @@ array implementation as a dependency.
 
 It's clear that SciPy functionality that relies on compiled extensions (C,
 C++, Cython, Fortran) directly can't easily be run on another array library
-than NumPy (see [C API](design_topics/C_API.md) for more details about this topic). Pure Python
+than NumPy (see [C API](design_topics/C_API.rst) for more details about this topic). Pure Python
 code can work though. There's two main possibilities:
 
 1. Testing with another package, manually or in CI, and simply provide a list

spec/2022.12/assumptions.md

@@ -26,7 +26,7 @@ of functions to be predictable from input dtypes only rather than input values.
 
 The only dependency that's assumed in this standard is that on Python itself.
 Python >= 3.8 is assumed, motivated by the use of positional-only parameters
-(see [function and method signatures](API_specification/function_and_method_signatures.md)).
+(see [function and method signatures](API_specification/function_and_method_signatures.rst)).
 
 Importantly, array libraries are not assumed to be aware of each other, or of
 a common array-specific layer. The [use cases](use_cases.md) do not require
@@ -39,7 +39,7 @@ for that is:
 
 Array libraries may know how to interoperate with each other, for example by
 constructing their own array type from that of another library or by shared
-memory use of an array (see [Data interchange mechanisms](design_topics/data_interchange.md)).
+memory use of an array (see [Data interchange mechanisms](design_topics/data_interchange.rst)).
 This can be done without a dependency though - only adherence to a protocol is
 enough.
 

spec/2022.12/purpose_and_scope.md

@@ -151,7 +151,7 @@ standard is shown in this diagram:
    _Rationale: this is an important topic for some array-consuming libraries,
    but there is no widely shared C/Cython API and hence it doesn't make sense at
    this point in time to standardize anything. See
-   the [C API section](design_topics/C_API.md) for more details._
+   the [C API section](design_topics/C_API.rst) for more details._
 
 4. Standardization of these dtypes is out of scope: bfloat16, extended
    precision floating point, datetime, string, object and void dtypes.

spec/2022.12/use_cases.md

@@ -59,7 +59,7 @@ array implementation as a dependency.
 
 It's clear that SciPy functionality that relies on compiled extensions (C,
 C++, Cython, Fortran) directly can't easily be run on another array library
-than NumPy (see [C API](design_topics/C_API.md) for more details about this topic). Pure Python
+than NumPy (see [C API](design_topics/C_API.rst) for more details about this topic). Pure Python
 code can work though. There's two main possibilities:
 
 1. Testing with another package, manually or in CI, and simply provide a list

spec/draft/assumptions.md

@@ -26,7 +26,7 @@ of functions to be predictable from input dtypes only rather than input values.
 
 The only dependency that's assumed in this standard is that on Python itself.
 Python >= 3.8 is assumed, motivated by the use of positional-only parameters
-(see [function and method signatures](API_specification/function_and_method_signatures.md)).
+(see [function and method signatures](API_specification/function_and_method_signatures.rst)).
 
 Importantly, array libraries are not assumed to be aware of each other, or of
 a common array-specific layer. The [use cases](use_cases.md) do not require
@@ -39,7 +39,7 @@ for that is:
 
 Array libraries may know how to interoperate with each other, for example by
 constructing their own array type from that of another library or by shared
-memory use of an array (see [Data interchange mechanisms](design_topics/data_interchange.md)).
+memory use of an array (see [Data interchange mechanisms](design_topics/data_interchange.rst)).
 This can be done without a dependency though - only adherence to a protocol is
 enough.
 

spec/draft/purpose_and_scope.md

@@ -151,7 +151,7 @@ standard is shown in this diagram:
    _Rationale: this is an important topic for some array-consuming libraries,
    but there is no widely shared C/Cython API and hence it doesn't make sense at
    this point in time to standardize anything. See
-   the [C API section](design_topics/C_API.md) for more details._
+   the [C API section](design_topics/C_API.rst) for more details._
 
 4. Standardization of these dtypes is out of scope: bfloat16, extended
    precision floating point, datetime, string, object and void dtypes.

spec/draft/use_cases.md

@@ -59,7 +59,7 @@ array implementation as a dependency.
 
 It's clear that SciPy functionality that relies on compiled extensions (C,
 C++, Cython, Fortran) directly can't easily be run on another array library
-than NumPy (see [C API](design_topics/C_API.md) for more details about this topic). Pure Python
+than NumPy (see [C API](design_topics/C_API.rst) for more details about this topic). Pure Python
 code can work though. There's two main possibilities:
 
 1. Testing with another package, manually or in CI, and simply provide a list