DataView Color clean-up

[corranwebster]

This PR does two things:

• switches from Instance(Color) to PyfaceColor traits
• fixes Fix DataView ColorValue expected test failures #708 (ColorValue was using an older iteration of the ValueType API)

We will probably revisit ColorValue again once there are custom editors available.

[codecov-commenter]

Codecov Report

Merging #709 into master will increase coverage by 0.76%.
The diff coverage is 93.33%.

@@            Coverage Diff             @@
##           master     #709      +/-   ##
==========================================
+ Coverage   39.76%   40.53%   +0.76%     
==========================================
  Files         493      502       +9     
  Lines       27259    27614     +355     
  Branches     4140     4185      +45     
==========================================
+ Hits        10840    11193     +353     
- Misses      15944    15950       +6     
+ Partials      475      471       -4     

Impacted Files	Coverage Δ
pyface/ui/qt4/data_view/data_view_item_model.py	49.30% <38.46%> (-0.70%)	⬇️
pyface/ui/wx/data_view/data_wrapper.py	86.36% <86.36%> (ø)
pyface/data_view/i_data_wrapper.py	88.46% <88.46%> (ø)
...face/data_view/data_models/row_table_data_model.py	91.25% <91.25%> (ø)
pyface/ui_traits.py	86.11% <93.93%> (+2.32%)	⬆️
pyface/data_view/value_types/color_value.py	95.45% <95.45%> (ø)
pyface/color.py	100.00% <100.00%> (ø)
pyface/data_view/abstract_value_type.py	97.72% <100.00%> (+0.29%)	⬆️
pyface/data_view/data_models/data_accessors.py	100.00% <100.00%> (ø)
pyface/data_view/data_wrapper.py	100.00% <100.00%> (ø)
... and 23 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 946a9c6...91472e1. Read the comment docs.

[kitchoi]

Please could we consider the pattern of splitting Str and CStr so that one trait type does strictly validation and the other does casting. I believe the casting capability in the color trait is motivated by migrating legacy code in enable amd chaco. The fact that one can assign primitive types (e.g. str) to an attribute to get an instance back makes tracking such usage in enable/chaco for refactoring difficult. (It is also surprising to read.) By having a separate trait type that doesn't do casting, we can prevent this anti-pattern cropping up in new code. Note that I am only talking about the 'validate' method on the trait type, not the instantiation. Accepting string in the trait type instantiation is fine.