Deprecation/removal of nios2 target support

[Sandra Loosemore <sloosemore@baylibre.com>]

Tomorrow I plan to push patches to mark the nios2 target as obsolete in 
GCC 14.

Background: Intel has EOL'ed the Nios II processor IP and is now 
directing their FPGA customers to a RISC-V platform instead.

https://www.intel.com/content/www/us/en/content-details/781327/intel-is-discontinuing-ip-ordering-codes-listed-in-pdn2312-for-nios-ii-ip.html

The Nios II hardware on loan from Intel that we were using for testing 
at Mentor Graphics/Siemens was returned around the first of the year. 
For some time we had been using QEMU to test the nios2-elf target, but 
we never had a QEMU test harness set up that would boot the Linux 
kernel, and user-mode QEMU on this target is too buggy/unmaintained to 
use for primary testing.  So the current situation is that none of the 
listed maintainers for any of the GNU toolchain components have access 
to a fully working test configuration any more, we have all moved on to 
new jobs and different projects, Intel has also moved on to a different 
platform, and our former contacts on Intel's Nios II team have moved on 
as well.  It seems like it's time to pull the plug.

Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove 
support from all toolchain components after the release is made.  I'm 
not sure there is an established process for obsoleting/removing support 
in other components; besides binutils, GDB, and GLIBC, there's QEMU, 
newlib/libgloss, and the Linux kernel.  But, we need to get the ball 
rolling somewhere.

I did do some GCC testing on both ELF and Linux Nios II targets around 
the end of December and another round about a month ago, so I believe 
GCC 14 will pretty much be in working order.  Beyond that, though, I 
think it would be better to remove support promptly, rather than having 
it hang around in an unmaintained/untestable zombie state, getting ever 
more bit-rotten.

-Sandra