[Docs] Fix minor rendering bugs (#196)

* [Docs] Fix indendation and rendering of Rationale

* add link for gh-1

* [Docs] Fix rendering of interchange mechanisms

Author: AnirudhDagar

spec/design_topics/data_interchange.md

@@ -12,20 +12,28 @@ The interchange mechanism must offer the following:
 
 1. Data access via a protocol that describes the memory layout of the array
    in an implementation-independent manner.
+
    _Rationale: any number of libraries must be able to exchange data, and no
    particular package must be needed to do so._
+
 2. Support for all dtypes in this API standard (see {ref}`data-types`).
+
 3. Device support. It must be possible to determine on what device the array
    that is to be converted lives.
+
    _Rationale: there are CPU-only, GPU-only, and multi-device array types;
    it's best to support these with a single protocol (with separate
    per-device protocols it's hard to figure out unambiguous rules for which
    protocol gets used, and the situation will get more complex over time
    as TPU's and other accelerators become more widely available)._
+
 4. Zero-copy semantics where possible, making a copy only if needed (e.g.
    when data is not contiguous in memory).
+
    _Rationale: performance._
+
 5. A Python-side and a C-side interface, the latter with a stable C ABI.
+
    _Rationale: all prominent existing array libraries are implemented in
    C/C++, and are released independently from each other. Hence a stable C
    ABI is required for packages to work well together._

spec/purpose_and_scope.md

@@ -187,10 +187,10 @@ extensions are dealt with_):
 
 7. Behaviour for unexpected/invalid input to functions and methods.
 
-  _Rationale: there are a huge amount of ways in which users can provide
-  invalid or unspecified input to functionality in the standard. Exception
-  types or other resulting behaviour cannot be completely covered and would
-  be hard to make consistent between libraries._
+   _Rationale: there are a huge amount of ways in which users can provide
+   invalid or unspecified input to functionality in the standard. Exception
+   types or other resulting behaviour cannot be completely covered and would
+   be hard to make consistent between libraries._
 
 
 **Non-goals** for the API standard include:

spec/use_cases.md

@@ -50,7 +50,7 @@ parallelism in some algorithms. However SciPy itself will not directly start
 depending on a GPU or distributed array implementation, or contain (e.g.)
 CUDA code - that's not maintainable given the resources for development.
 _However_, there is a way to provide distributed or GPU support. Part of the
-solution is provided by NumPy's "array protocols" (see gh-1), that allow
+solution is provided by NumPy's "array protocols" (see [gh-1](https://github.com/data-apis/array-api/issues/1)), that allow
 dispatching to other array implementations. The main problem then becomes how
 to know whether this will work with a particular distributed or GPU array
 implementation - given that there are zero other array implementations that