volatile: revert changes introduced by #95

[jiangliu]

#95 fixed the problem of torn reads/writes caused by the implementation
of read/write_obj essentially leveraging the environment specific
memcpy, and the implicit assumption that read/write_obj perform atomic
accesses up to a certain size at aligned addresses. Meanwhile, we added
the load/store operations to Bytes which provide explicit atomic access
semantics.

Now there are three possible types of memory access methods:

1. atomic access: VolatileSlice::load/store() for integer atomic data
   types
2. volatile access: {VolatileRef|VolatileArrayRef}::{load|store()|
   copy_from|copy_from} when size_of::() > 1
3. normal access: all other byte stream oriented memory accesses

Explicitly states that GuestMemory/Bytes are byte stream oriented, and do
not guarantee atomicity. Callers need to be care to choose the access method,
in preference for both safety and high performance.

Signed-off-by: Liu Jiang [email protected]

Fixes: #95

[alexandruag]

As we mentioned in #123, this may have more profound implications on the consumers of vm-memory. Is it ok if we try to merge and release the other active PRs first, and then circle back to this one and release it as well?