Add change record(s) for Migrate 2.6

First off, let me point out that arguments() still works - it's deprecated in favor of the subfield notation introduced a couple of point releases back, but if someone insists on doing things the hard way they still can. I'm doing my best to get people using current best practices, however.

Auto-registration is kind of an interesting case. It's not strictly speaking part of the API, but a shortcut that on a cache clear Migrate used to register migrations simply from the existence of a new class derived from Migration. Unfortunately, the discovery of new Migration classes breaks badly in the presence of modules implementing classes based both on Migrate and another module (commonly Views) if the other module is disabled. As OO techniques become more common in Drupal, and more and more modules are implementing classes based on Views, or Rules, or other object-oriented APIs, this situation will only get worse. So, the offending auto-registration technique was deprecated in Migrate 2.5, and is being eliminated in Migrate 2.6. This does mean that modules that implemented Migration classes without explicitly registering them, and didn't make the changes for Migrate 2.5 when the technique was deprecated, will now need to make code changes to get their migrations registered (usually in hook_migrate_api).

Frankly, it didn't even occur to me to bump up the major version, since this is a narrow change (no significant revamping of the API) and I've already got Migrate 3 on Drupal 8 (major refactoring) running through my head, but I take your point that it will require code changes for some modules. However, I think the bottom line is to minimize disruption to implementers of the Migrate API, and upping the major version number would be even more disruptive, requiring all implementers to change their hook_migrate_api() to return a version of 3 instead of 2, in addition to making the changes necessary to register their migrations. So, I'm not inclined to bump up the major version number at this time. I am open to hearing further arguments for making the change, however.

Clarified that the problem is breaking backwards compatibility.

I think @mikeryan's arguments make sense, but some change records for the upcoming 2.6 are definitely needed!

This is pretty frustrating. We updated Migrate on a client's site from 7.x-2.5 to 7.x-2.8 in April last year to get the security update. Now they want to run a migration and it's broken due to the changes in 7.x-2.6 and I'm banging my head trying to fix it. Really should have been a 3.x branch IMO with a security update to 2.x.