feat: add new Cell/Row override to Hybrid Selection Model

[ghiscoding]

add a selectionType (can be one of 'cell', 'row', 'mixed'), by default it's mixed and also the 'cell' doesn't do much except ignore rowSelectColumnIds when provided. But the 'row' type is really the one I wanted to add and that I need in order to fully replace the Cell & Row Selection Models (which is what I'll do in my next Slickgrid-Universal major version, I'll delete previous models and only keep the new Hybrid in my project, thanks to @6pac for this new hybrid model). So the new 'row' fixes an issue that the new Hybrid Selection had some problems with, which was that unless you're on the rowSelectColumnIds column, then it defaults to a cell selection, but in some grids the user may want to use the new Hybrid Model but really use it as a Row Selection only and we'll now be able to do this via { selectionType: 'row' } as Hybrid Model option.

... in other words, it's exactly as if we were using the previous SlickRowSelectionModel, but in reality we are using the new SlickHybridSelectionModel({ selectionType: 'row' }) with a new selection type option. So this is great if we want to have the same previous behavior but with the new model (which is what I wanted)

Previous code, without fully hybrid but not exactly great for row selection

With new option { selectionType: 'row' }, we now explicitely use a Row Selection even with the Hybrid Model

[6pac]

OK, so basically we are dropping the RowSelectionModel and CellSelectionModel and adding this SelectionType parameter, where 'row' forces RowSelectionModel behaviour, 'cell' forces CellSelectionModel and 'mixed' HybridSelectionModel.

I'm OK with this. On the minus side, these are all plugins so you could say if you only want row selection, use RowSelectionModel. Choosing the one that does only what you want means simpler code to deal with (in the case of RowSelection, a LOT simpler).
On the plus side, nearly all of the Row/Cell SelectionModel code is in Hybrid, so maintaining the three is not great for code re-use.

I think on balance, go ahead. I would possibly retain the RowSelectionModel and CellSelectionModel in case people would rather use them as a template for custom providers in future.

[ghiscoding]

yeah my use case is a bit different, if we compare your lib SlickGrid, it requires the user to assemble everything themselves... however in my lib (Slickgrid-Universal), I already pre-assemble most stuff including these selection models, so now instead of previously having 2 models that are pre-loaded (that all users build and imports), I'm now having 3 models which increases my project size. So I was comparing and looking at the code & behaviors and found that in order to fully replace both Cell & Row Models with the new Hybrid Model, I needed this change so that it behaves the same. Again, like I said, in my lib, I will only have 1 model in the future (just the Hybrid Model), but in order to do that, I need to have same behaviors as before, this change helps in going in that direction