Implement --idlist options on rollback and messages

I've written a patch for this, by overriding \Drupal\migrate_tools\MigrateExecutable::rollback based on \Drupal\migrate\MigrateExecutable::rollback.
It's actually a very straightforward change, just three lines when compared to Core - see the attached migrate_tools-rollback_core-diff.txt file.

Drush 9 support is now in existence. Can we rewrite the features for drush 9 instead of drush 8?

Updated patch to work with Drush 9.

While reviewing this, I see we really should refactor that code in core as this is basically a copy/paste from there. And there are problems with it. Let's fix #2999478: Refactor MigrateExecutable::rollback() first, then come back and make this a lot easier and less brittle and commit this then.

I'm curious how this approach effects all the existing methods of filtering by id list? I wonder if this means we can remove all that existing logic? And if this will make things faster/easier to iterate?

Fixing phpcs.

I'm almost certain we can remove more code. And add more functionality. Let's extend this to messages as well. And maybe there is an easy way to escape the ids to answer #2955034: No way to escape commas and colons in the idlist parameter for string ids that may contain them.?

So removing the filter on the preparerow event breaks the --idlist option for imports? Can you implement a similar iterator filter on getSource() to filter the import and avoid filtering on the event?

Much of this is completely untested, but the theory of it is that it would work...

And we'd have a consistent implementation of idlist filtering.

Added some tests. They passed on local with the core patch... So that's exciting.

Entirely uninteresting phpcs fixes.

Core patch has landed. So let's do a test run now.

We need to add some type of version check to the test if we want this to land before 8.7 goes stable. See the failure in #14.

Here, we now test and do things in a BC manner on 8.6. I also tested locally on 8.5 too.

What is the reason/use-case for adding the new --idlist-delimiter. Is there a scenario where ':' is not working?

If I recall, there were some systems that use UUIDs with the parts of the UUID delimited by that. ABCD:1234:ABCD:1234, or something like that.

@heddn, if I’m reading correctly the code, that can be handled as --idlist=1:”id:containing:colons:1”,2:”2nd:id”

It was also a compound ID. Where there was a UUID and a langcode as part of the "ID".