Makefile changes

• Fixed typo; CLI_USE= should have been CLI_USES=
• Added 'shebangfix' to CLI_USES=
• Removed extraneous whitespace (to satisfy portlint)

Re-upload... forgot to squash my first stab at it with the second stab that extended it to all MIPS32 and excluded 64-bit variants.

Further proposal (the patch doesn't do this yet): cron should not override PATH when reading a user crontab; whether it should use the user's path, or daemon's path, rather than the hardcoded default when processing the system crontab is a more open question.

In D21681#473203, @jmallett wrote:

I would wonder if it makes sense to implement these in terms of cmpset operations on register-sized quantities in C with the appropriate arithmetic shifts, rather than doing the assembly sort of half by-hand. That's maybe less optimal, but do we have performance-critical 8- and 16-bit atomics in performance-critical areas? I've always been skeptical of smaller-than-register atomics and tend to resist them, so that may just be a personal bias. I can't speak to correctness beyond that.

Add 8 and 16 bit [f]cmpset for armv4/5 (kernel only).

In D21681#473240, @arichardson wrote:

I believe that splitting the operation into two asm blocks with C code between will break at -O0 since any variable access goes via the stack. This might cause the sc to fail.
I would prefer if atomic.h used C11 atomics or the __atomic_foo() builtins with a memory mode instead (in which case the compiler automatically does the masking for smaller sizes). However, it seems that requires GCC4.7+ so it would have to wait until GCC4.2 is gone.
Those builtins will also work for CHERI so using them would reduce the size of the CheriBSD diff, too.

I believe that splitting the operation into two asm blocks with C code between will break at -O0 since any variable access goes via the stack. This might cause the sc to fail.

Use constants defined in D21693.

I would wonder if it makes sense to implement these in terms of cmpset operations on register-sized quantities in C with the appropriate arithmetic shifts, rather than doing the assembly sort of half by-hand. That's maybe less optimal, but do we have performance-critical 8- and 16-bit atomics in performance-critical areas? I've always been skeptical of smaller-than-register atomics and tend to resist them, so that may just be a personal bias. I can't speak to correctness beyond that.