Revert change that instructs you to target netX.0-windows10.0.19041

[idg10]

As discussed at #1889 (comment), PR #1442 looks like it might cause more problems than it solves.

The following two tables, extracted from that original comment, cover the most important facts. With today's Rx 5.0 package, here's what happens with a variety of host application TFMs and developer intentions:

App TFM	Want WPF/WinForms?	Rx TFM	Effect
net5.0	No	net5.0	App gets the non-WPF/WinForms Rx
net5.0-windows	No	net5.0	App gets the non-WPF/WinForms Rx
net5.0-windows	Yes	net5.0	Developer baffled by missing support for WPF/WinForms
net5.0-windows10.0.19041 (or later)	No	net5.0-windows10.0.19041	App gets the WPF and WinForms functionality whether or not it's wanted (which causes horrendous app bloat for some .NET app packaging models); Developer can't choose simply to use the non-WPF/WinForms version
net5.0-windows10.0.19041 (or later)	Yes	net5.0-windows10.0.19041	App gets the WPF and WinForms functionality

@dotMorten's change was designed to address the 3rd entry in that list, where the developer wants either WPF or Windows Forms features, but hasn't realised that they need to make their app target an OS-version-specific in order to get those features.

Here's the situation after @dotMorten's change:

App TFM	Want WPF/WinForms?	Rx TFM	Effect
net5.0	No	net5.0	App gets the non-WPF/WinForms Rx
net5.0-windows	No	net5.0	Build error telling developer to make their app target net5.0-windows10.0.19041 or later; Developer can't choose simply to use the non-WPF/WinForms version
net5.0-windows	Yes	net5.0	Build error helpfully telling developer what to do
net5.0-windows10.0.19041 (or later)	No	net5.0-windows10.0.19041	App gets the WPF and WinForms functionality whether or not it's wanted (which causes horrendous app bloat for some .NET app packaging models); Developer can't choose simply to use the non-WPF/WinForms version
net5.0-windows10.0.19041 (or later)	Yes	net5.0-windows10.0.19041	App gets the WPF and WinForms functionality

Neither of these is good, but our concern is that since Rx 5.0 has been out for 2 years without @dotMorten's change ever being included, this would risk breaking a lot of code.

As described in our 2023 roadmap our plans are roughly as follows:

• v6.0: support .NET 6 and .NET 7 and enabling building on current version of Visual Studio and recent .NET SDKs, while making as few changes as possible
• v7.0: address the numerous problems around UI framework support in Rx properly by splitting UI framework code back out into separate packages

That change in v7.0 is, we believe, a better solution to the problem #1442 attempts to address. Developers need to be able to decide whether they want WPF or Windows Forms features independently of their choice of target runtime. (So they should be free to target, say, net6.0-windows10.0.19041 without being forced to have Rx's WPF and Windows Forms features.)

Since a) in v6 we don't want to aggravate the existing situation in which people end up with unwanted WPF and Windows Forms dependencies and b) we believe we can provide a better solution in v7, we want to undo the change in #1442. This will make Rx 6.0 behaviour will be consistent with what's in the currently shipping Rx 5.0.