[WinForms] Really fix ToolStrip background (#11287)

## Problem

Even after #10942, menus and toolstrips still look awful with a dark theme:

![toolstrip](https://user-images.githubusercontent.com/1559108/46361551-8e6dea80-c633-11e8-97d1-242612b4b5cf.png)

## Previous attempt

#10942 was a first stab in the dark at what was going on here, before I managed to get mono to compile for testing. I was hopeful that it would address this, but the problem was different.

## Another red herring

Later I thought the problem might be that `SystemColors.ButtonFace.IsSystemColor` was `false`. It looked like this might have caused the runtime to interpret `ButtonFace`'s special 168 value as an RGB code instead of a system color marker.

This fix had no effect (see below for true cause), but I'll include it anyway; the lower bound of the upper system colors block needs to decrease from 170 to 168 to allow `ButtonFace` and `ButtonHighlight` to be considered system colors:

https://github.com/mono/mono/blob/44db64c620c2c957a49b3f5a69cb09c19c1c8c1a/mcs/class/System.Drawing/System.Drawing/KnownColor.cs#L200-L203

## Actual cause

The toolstrip color comes from `ProfessionalColorTable.ToolStripGradientBegin` and `ProfessionalColorTable.ToolStripGradientEnd`. The latter color is hard coded to a light shade, but the former defaults to `SystemColors.ButtonFace`.

These are the colors that are loaded from the GTK system theme:

https://github.com/mono/mono/blob/b104565ccfde477fc7b6308f2d3e4efff0af5848/mcs/class/System.Windows.Forms/System.Windows.Forms/X11DesktopColors.cs#L111-L116

Note that `ButtonFace` is not among them. This means that it uses a compile time default, and is not a good choice for the background of a control. `ToolStrip` is using it anyway, but other controls use `SystemColors.Control` instead.

## Changes

There are two obvious ways to fix this:

1. Use `SystemColors.Control` instead of `SystemColors.ButtonFace` in `ProfessionalColorTable`
2. Load `SystemColors.ButtonFace` from the system theme

This pull request does both. In addition, it also sets the other end of the toolstrip gradients to `SystemColors.ControlLight` instead of a hard coded value. The choice of `ControlLight` was made because in those cases where alternate hard coded values were available for both sides of the gradient, the "other" side was consistently lighter. Now it looks better:

![image](https://user-images.githubusercontent.com/1559108/47258840-efd0ee80-d466-11e8-842f-2fed8b3b9d82.png)

1 files changed, 1 insertions, 1 deletions

diff --git a/mcs/class/System.Drawing/System.Drawing/Color.cs b/mcs/class/System.Drawing/System.Drawing/Color.cs
index 2f317250e59..2929145d5ba 100644
--- a/mcs/class/System.Drawing/System.Drawing/Color.cs
+++ b/mcs/class/System.Drawing/System.Drawing/Color.cs
@@ -160,7 +160,7 @@ namespace System.Drawing
 			} else {
 				c = new Color ();
 				c.state = (short) (ColorType.ARGB | ColorType.Known | ColorType.Named);
-				if ((n < 27) || (n > 169))
+				if ((n < 27) || (n >= 168))
 					c.state |= (short) ColorType.System;
 				c.Value = KnownColors.ArgbValues [n];
 			}