Remove CupertinoSystemColors in favor of CupertinoColors

[LongCatIsLooong]

Description

Making iOS 13 colors compile-time constants. Since we don't change the appearance of widgets based on the OS version, dynamically updating color values may not be the best strategy. This would allow us to use these dynamic colors as default parameters.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I updated/added relevant documentation (doc comments with ///).
• All existing and new tests are passing.
• The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require Flutter developers to manually update their apps to accommodate your change?

• Yes, this is a breaking change (Please read Handling breaking changes). https://groups.google.com/forum/#!topic/flutter-announce/pMYPTvjWCX4

[justinmc]

LGTM

Just a very tiny spelling nitpick :)

[justinmc]

Some of your comments spell it "grey" and some spell it "gray". I guess everything should be "gray" since that's how Apple spells it?

[HansMuller]

LGTM too.

In material/colors.dart will spell "grey" which I think is the British version. For the sake of consistency, we should probably carry on with grey.

[LongCatIsLooong]

@HansMuller @justinmc should I apply /gray/grey/ to existing constant names (e.g. inactiveGray, darkBrackgroundGray) too?

[Hixie]

why do we pass 0 up to the constructor instead of just passing _effectiveColor.value and not overriding value?

[LongCatIsLooong]

Then the constructor can't be made const (#39430). IMO the benefit of being able to make a const CupertinoDynamicColor and use it in a function as the default parameter outweighs the cost, e.g.

const Color _kDefaultColor = Color(...);
class ThumbPainter extends CustomPainter {
  const ThumbPainter({
     this.color = _kDefaultColor,
  }) : super(...);
}

Now if I want to make _kDefaultColor a CupertinoDynamicColor, without the const constructor I'll have to break the API. Also works better with NNBD.