doc: fix a number of fragment specifiers.

In general, the anchors and fragments of the restructured text
"translation" of the documentation seems to be a total mess. Some
of the anchors are `#id1`, which is not desirable. Some anchors
have a `man-` prefix, while others don't. I have no idea why the
tool generates these anchors differently.

There are also a lot of broken references in the text. These seem
to have been poorly translated by some automated tool.

doc/manual/conversion-and-promotion.rst

@@ -371,7 +371,7 @@ dictates that promoting a rational with a float results in the same type
 as promoting the numerator/denominator type with the float.
 
 This small handful of promotion rules, together with the `conversion
-methods discussed above <#Case+Study:+Rational+Conversions>`_, are
+methods discussed above <#case-study-rational-conversions>`_, are
 sufficient to make rational numbers interoperate completely naturally
 with all of Julia's other numeric types — integers, floating-point
 numbers, and complex numbers. By providing appropriate conversion

doc/manual/functions.rst

@@ -70,7 +70,7 @@ and can be passed around like any value:
 
 There are two other ways that functions can be applied: using special
 operator syntax for certain function names (see `Operators Are
-Functions <#Operators+Are+Functions>`_ below), or with the ``apply``
+Functions <#operators-are-functions>`_ below), or with the ``apply``
 function:
 
 ::

doc/manual/strings.rst

@@ -279,7 +279,7 @@ Unicode and UTF-8
 -----------------
 
 Julia fully supports Unicode characters and strings. As `discussed
-above <#Characters>`_, in character literals, Unicode code points can be
+above <#characters>`_, in character literals, Unicode code points can be
 represented using unicode ``\u`` and ``\U`` escape sequences, as well as
 all the standard C escape sequences. These can likewise be used to write
 string literals:
@@ -599,7 +599,7 @@ Byte Array Literals
 ~~~~~~~~~~~~~~~~~~~
 
 Some string literal forms don't create strings at all. In the `next
-section <#Regular+Expressions>`_, we will see that regular expressions
+section <#regular-expressions>`_, we will see that regular expressions
 are written as non-standard string literals. Another useful non-standard
 string literal, however, is the byte-array string literal: ``b"..."``.
 This form lets you use string notation to express literal byte arrays —
@@ -870,4 +870,3 @@ For example, the following regex has all three flags turned on:
  <!-- ### Exercises
  - Given an ASCIIString `s`, print it in reverse order. [Answer](answer_reverse.md)
  - Write a function to generate a random string consisting of the letters A-Z, a-z, and the numbers 0-9. [Answer](answer_randstring.md) -->
-

doc/manual/types.rst

@@ -250,7 +250,7 @@ subtype of its right operand:
 Since abstract types have no instantiations and serve as no more than
 nodes in the type graph, there is not much more to say about them until
 we introduce parametric abstract types later on in `Parametric
-Types <#Parametric+Types>`_.
+Types <#man-parametric-types>`_.
 
 Bits Types
 ----------
@@ -416,7 +416,7 @@ The ``is`` function confirms that the "two" constructed instances of
 
 There is much more to say about how instances of composite types are
 created, but that discussion depends on both `Parametric
-Types <#Parametric+Types>`_ and on :ref:`man-methods`, and is
+Types <#man-parametric-types>`_ and on :ref:`man-methods`, and is
 sufficiently important to be addressed in its own section:
 :ref:`man-constructors`.
 
@@ -1068,7 +1068,7 @@ happens, are all composite values and thus all have a type of
  CompositeKind
 
 The reader may note that ``CompositeKind`` shares with the empty tuple
-(see `above <#Tuple+Types>`_), the distinction of being its own type
+(see `above <#tuple-types>`_), the distinction of being its own type
 (i.e. a fixed point of the ``typeof`` function). This leads any number
 of tuple types recursively built with ``()`` and ``CompositeKind`` as
 their only atomic values, which are their own type: