Make obsolete abstract virtual

[fredericDelaporte]

I have realized than obsoleting an abstract member is not very nice to implementors: it forces them to override an obsolete member. Once dropped, their code will no more compile, while the purpose of Obsolete is to allow consumers to make required changes for next version and avoid errors due to upgrading.

Instead, we should switch such abstract member to virtual.

This is a kind of follow-up to #1599, since the only obsoleted abstract I have found was introduced there. (I have thought of this subject because I was starting to obsolete abstract members for another subject.)

There is somewhat a similar trouble with obsoleted interface members, but there is nothing we can do for them, and furthermore the implementor can implements them in a way that will not break compilation once they are dropped, contrary to abstract members.

[bahusoid]

My only concern is method "discoverability" for new implementors. Yes - you are forced to implement obsolete method but you also see a proper new method to override in obsolete message. With this method virtual it's not clear what should be overridden in the first place.

If you think it's OK - no objections from my side. Code is definitely cleaner this way.

[fredericDelaporte]

They will still have an exception if they do some minimal testing of their implementation. Of course, it is better to know that at compilation time, but that is the reason why the non obsoleted method is flagged for conversion to abstract in 6.0.
I do not think using an obsolete abstract to hint at the virtual to override is adequate for "compensating" during the "transition period", due to the drawback it has of not allowing implementors to actually get their code ready for the next major version.