Selection models

I have implemented a `BaseSelectionModel` component that is intended to be the sole child of an `AbstractItemView` like the `TableView`. It has an intentionally sparse interface. It has methods to get and set the selection and an `Event` for when the selection changes (and also methods and an `Event` for the so-called "current" cell, but I haven't done much with that). More interesting interfaces are meant to be implemented as subclasses. I provide one such `RowSelectionModel` for `TableViews` and the future `ListView` that synchronizes the selection with a `selected_rows = List(Int)` much like the interface exposed by the `TabularEditor`.

A few points for review:

* Since the Qt object behind the `QtBaseSelectionModel` is not a `QWidget`, I had to work around some of the assumptions in `QtBaseComponent`. It would be nice, but not necessary to relax some of those assumptions. For now, I just keep the `.widget` attribute `None` and guard against that possibility in `QtBaseComponent`.

*SCC - I'm still not entirely convinced that the selection model should be an Enaml component instead of just a
regular traits object. Since the ItemModel driving the view is a regular object, this would have parity. It would also
eliminate the issues that need to be worked around to make it a BaseComponent. If the selection model is just 
an attribute on the ItemView it's able to be swapped in and out dynamically without needing to use an Include, 
which is geared to components anyhow. If the user is already creating models to drive the view, creating another
model to drive the selection shouldn't be that much more cognitive load.*

* Some flags controlling selection UI behavior live on `AbstractItemView`. This follows Qt's architecture. However, this does mean that the user may set these flags at odds with the semantics demanded by a particular `BaseSelectionModel` subclass. For example, leaving the default `selection_behavior = 'items'` while using a `RowSelectionModel` may not work well. We could move these flags onto the selection models such that subclasses could provide sensible defaults and to "package up" all of the selection options in one place in the Enaml hierarchy. The only oddity would be that the `QtBaseSelectionModel` implementation would be reaching up to call methods on its parent widget. I'd be willing to live with that internal oddity to make things safer and more streamlined for Enaml users.

*SCC - I'm +1 on having all selection related stuff on the selection model instead of split between item view 
and selection model.*

* In the implementation of `RowSelectionModel`, I need to do two-way synchronization between a trait and the Qt object. When reading the Qt values and setting the trait values to match, we don't want a notification coming the other way to set the Qt values. I follow Traits UI's example, and keep a flag that controls when we are setting the trait "internally" such that the "set Qt values from the trait" handler will do nothing when it gets notified. We will need to do this often in `Component` implementations. We could generalize this and make it generally available as part of the `BaseComponent` interface. We could keep a set (well, a bag would be better) of trait names that are currently being set, a context manager method that adds the trait name to the set before we read the toolkit values and set the trait then removes the trait name from the set afterwards, and a method to check if a trait name is in the set.

*SCC - there is a guard.py module in the root directory with a singleton guard object that is in use in a bunch of 
place to guard against recursion. It's not a context manager (since it used to deal with deferred callbacks) but
it may serve your purpose if only requiring one extra line of code. The plus side is that you don't need to pay
the memory cost of extra attributes all over the place.*

* I haven't tested if `Include` works well.

*SCC - The way things are setup now, it won't. I've made a comment on the use of '_subcomponents' is the 
selection model where the dependency should really be on 'children'. BaseComponent iterates over the 
subcomponents and uses their contributed items to form the list of children.*