Clean up documentation issues around periods (TextureGroup#1490)

There were so unnecessary `'` around periods for some reason. Just deleting those because they are distracting.

docs/_docs/corner-rounding.md

@@ -55,7 +55,7 @@ The final consideration is to determine if all four corners cover the same node
 
 Precomposited corners refer to corners drawn using bezier paths to clip the content in a CGContext / UIGraphicsContext (`[path clip]`).  In this scenario, the corners become part of the image itself — and are "baked in" to the single CALayer.  There are two types of precomposited corners. 
 
-The absolute best method is to use **precomposited opaque corners**.  This is the most efficient method available, resulting in zero alpha blending (although this is much less critical than avoiding offscreen rendering).  Unfortunately, this method is also the least flexible; the background behind the corners will need to be a solid color if the rounded image needs to move around on top of it.  It's possible, but tricky to make precomposited corners with a textured or photo background - usually it's best to use precomposited alpha corners instead'.'
+The absolute best method is to use **precomposited opaque corners**.  This is the most efficient method available, resulting in zero alpha blending (although this is much less critical than avoiding offscreen rendering).  Unfortunately, this method is also the least flexible; the background behind the corners will need to be a solid color if the rounded image needs to move around on top of it.  It's possible, but tricky to make precomposited corners with a textured or photo background - usually it's best to use precomposited alpha corners instead.
 
 The second method involves using bezier paths with **precomposited alpha corners**.  This method is pretty flexible and should be one of the most frequently used.  It does incur the cost of alpha blending across the full size of the content, and including an alpha channel increases memory impact by 25% over opaque precompositing - but these costs are tiny on modern devices, and a different order of magnitude than `.cornerRadius` offscreen rendering.
 
@@ -84,7 +84,7 @@ Clip corners applies to two main types of corner rounding situations:
 
 There are a few, quite rare cases in which it is appropriate to use `.cornerRadius.` These include when there is dynamic content moving _both_ through the inside and underneath the corner.  For certain animations, this is impossible to avoid.  However, in many cases, it is easy to adjust your design to eliminate one of the sources of movement.  One such case was discussed in the section on corner movement.
 
-It is much less bad, and okay as a shortcut, to use `.cornerRadius.` for screens in which nothing moves.  However, *any* motion on the screen, even movement that doesn't involve the corners, will cause the `.cornerRadius.` performance tax.  For example, having a rounded element in the navigation bar with a scrolling view beneath it will cause the impact even if they don't overlap.  Animating anything onscreen, even if the user doesn't interact, will as well.'  Additionally, any type of screen refresh will incur the cost of corner rounding. 
+It is much less bad, and okay as a shortcut, to use `.cornerRadius.` for screens in which nothing moves.  However, *any* motion on the screen, even movement that doesn't involve the corners, will cause the `.cornerRadius.` performance tax.  For example, having a rounded element in the navigation bar with a scrolling view beneath it will cause the impact even if they don't overlap.  Animating anything onscreen, even if the user doesn't interact, will as well.  Additionally, any type of screen refresh will incur the cost of corner rounding. 
 
 ### Rasterization and Layerbacking