Remove outdated documentation note about CT operating in 96 DPI

As extensively discussed and documented in #1484, Core Text does
not operate in 96 DPI. Core Text doesn't actually have a concept of
DPI internally, as it doesn't rasterize anything by itself, it just
generates vector paths that get passed along to Core Graphics.

In practice this means Core Text operates in the classical macOS
logical DPI of 72, with one typographic point corresponding to one
point in the Core Graphics coordinate system, which for a normal
bitmap context then corresponds to one pixel -- or two pixels for
a "retina" context with a 2x scale transform.

As of f401f85a5a, we no longer apply
any assumptions in HB about the target DPI being different than the
72 DPI used by CT, for example to account for the Web's standard of
96 DPI, so let's remove the documentation that still indicated this
was necessary.

docs/usermanual-integration.xml

@@ -518,18 +518,6 @@
       <type>hb_font_t</type> font object. Core Text uses this value to
       implement optical scaling. 
     </para>
-    <para>
-      When integrating your client code with Core Text, it is
-      important to recognize that Core Text <literal>points</literal>
-      are not typographic points (standardized at 72 per inch) as the
-      term is used elsewhere in OpenType. Instead, Core Text points
-      are CSS points, which are standardized at 96 per inch.
-    </para>
-    <para>
-      HarfBuzz's font functions take this distinction into account,
-      but it can be an easy detail to miss in cross-platform
-      code. 
-    </para>
     <para>
       As a final note, you may notice a reference to an optional
       <literal>coretext</literal> shaper back-end in the <xref