Remove remaining uses of setErrNo and deprecate SUPPORT_ERRNO setting

[sbc100]

Aside from the setErrNo library function SUPPORT_ERRNO also controlled the building the malloc and sbrk. However, just setting errno to ENOMEM didn't seem to have any effect on the code size for any of our micro benchmarks. This may be because LTO can completely eliminate the write to errno when there are no readers, or it could be that errno usage exists in in even the smallest program already so removing from malloc alone makes no difference.

[dschuff]

so IIUC what's really happening here is that C runtime functions are all still setting errno where appropriate but errno is basically not exposed to JS and there are no JS functions that need to set it, and therefore we don't need to have the function for setting it from JS. So the setting was always a bit of a misnomer?
If that's right, the documentation should probably mention that (in case users actually use errno in their C code, they'll understand that they won't be broken).

[sbc100]

so IIUC what's really happening here is that C runtime functions are all still setting errno where appropriate but errno is basically not exposed to JS and there are no JS functions that need to set it, and therefore we don't need to have the function for setting it from JS. So the setting was always a bit of a misnomer? If that's right, the documentation should probably mention that (in case users actually use errno in their C code, they'll understand that they won't be broken).

Yes, IIUC traditionally C function always set errno internally and ERRNO_SUPPORT was only about exposing errno setting to JS code.

The ERRNO_SUPPORT setting only started to effect native in d98572b, but it was/is strictly limited to malloc and sbrk. Errno support for all other C library function is (and always way) unconditional.

As far as I can tell there is no code size regression from making malloc/sbrk just like the rest of libc.

[sbc100]

I think the reason we don't see any code size regressions from having malloc/sbrk reference errno is that its almost impossible to build a native program without any errno references. Even strdup references errno.

The cost of supporting errno on the native side is tiny and likely very hard to avoid.

[sbc100]

I'll wait for @kripken and @juj to weight in in case there is some code size benefit that I'm not seen (and we are not testing for)

[kripken]

lgtm % comments/questions

[kripken]

Suggested change

	that it controls is no longer used by emscripten. Use of `errno` from in C
	that it controls is no longer used by emscripten. Use of `errno` from C

[kripken]

Makes sense, thanks for checking that.

Seems reasonable given emmalloc is our compact allocator, so as long as we don't regress that sgtm.