drop volatile from __cpu_simplelock_t typedef

[Antti Kantee <pooka%iki.fi@localhost>]

__cpu_simplelock_t was born 15+ years ago with the following commit message:

=== snip ===
Let each platform typedef the new __cpu_simple_lock_t, which should
be the most efficient type used for the atomic operations in the
simplelock structure, and should also be __volatile.
=== snip ===

So, thinking about fixing lib/49989, I started wondering why "volatile" 
is necessary in the simplelock typedefs.  "should also be" doesn't 
explain much, and may just be there because that's what the 
pre-simplelock_t definitions used.  Shouldn't simplelocks always be 
operated on with atomic instructions and instruction barriers or some 
non-SMP equivalent thereof?  Assuming so, volatile in the typedef 
doesn't do anything except probably throw compilers off and therefore we 
should drop volatile from the typedefs.

RAS might need volatile (not sure yet), but that can probably be pushed 
inside the RAS sequence instead of exposing it everywhere.

Thoughts?  Seems like the right thing to do irrespective of lib/49989.