When `RELEASE` is set, then `inc/version.h` configures some
defines appropriately, including `BIGATOMS`, `BIGVM`, and
`NEWCDRCODING`. There's no need to manage it directly on
the compiler command line.
* Always follow NEW_STORAGE code paths.
This removes the code paths for the pre-NEW_STORAGE code.
* Remove NEW_STORAGE from build system.
The code no longer refers to `NEW_STORAGE`, so we can remove
this from the build system.
This flag was for SunOS 3 and 4 on sun3 hardware (68k).
It enabled some unsafe optimizations via assembler. This hasn't
actually been built since the DOS port (since the header for this
was renamed, but the code in `xc.c` wasn't updated).
The optimizations here made assumptions that were specific to the
68k hardware and register allocation. They aren't likely to be
of much use moving forward, and we've got plenty of safe performance
improvements from the last 30 years of hardware advances.
The FSERROR define is on all the time now. It was not controlling
all of the functionality, with many places setting Lisp_errnno
outside of the code controlled by the define.
