Allow custom actions for non-DataObject based GridFields

[gurucomkz]

SilverStripe 5 allows GridField to arbitrary data types now, but when was trying to make use of that feature I encountered types mismatches in this package's codes since it required DataObject to be passed.

This pull request attempts to relax those restrictions to let Custom Actions to work with the new SS5 feature.

TODO:

• Change function parameters' classes
• Fix forwardActionToRecord()
• Add tests
• Change the docs/readme if needed

[lekoala]

this sounds like a great idea but i'm also wondering how you are going to bind the "record" to the action? (the getRecord method in the admin works with a DataObject too...)
or is the goal simply to make sure you don't get any errors when using arbitrary types?

anyway, any improvement is welcome let me known when your pr is ready :-)

[gurucomkz]

...how you are going to bind the "record" to the action? (the getRecord method in the admin works with a DataObject too...) or is the goal simply to make sure you don't get any errors when using arbitrary types?

I don't think I need worry much about that. ModelAdmin works with DataObject and there's nothing else to do there. However, this module is still invoked when we display Viewables in a hand-configured GridField - and that is where we may still want to have actions.

My particular use case is to convert a set of HUGE MySQL tables (started as an experiment but overgrown over the last 2 years) into MongoDB while retaining the rest of the functionality. That includes keeping custom actions. So, initially I used to have ModelAdmin entities for working with them. Now I'm building a custom ModelAdmin implementations that will have their own delivery mechanism and getRecord returns whatever I want. I believe that everyone else who's going to be going through the same exercise would have to do the same. So - no problems there, I suppose.