Clarify USM behavior

[gmlueck]

Clarify several things about USM:

• We did not have precise rules about when USM memory allocated for
  one device could be accessed by another device. This is now
  clarified, and a few new device aspects were added to tell
  applications when this is allowed.

• We did not have precise rules about sharing a USM memory region
  between two devices when those devices do not support "concurrent
  access" to USM. Add rules to explain this.

• We were not clear about the role of the context that is used when
  allocating USM memory. Clarify how this affects the accessibility
  of USM memory on various devices.

• Replace the term "unified addressing", which was poorly defined, with
  a new term "stable addresses", and clarify exactly what guarantees we
  provide about uniqueness of pointers for the three USM allocation
  types.

Partially addresses KhronosGroup#184.
Closes KhronosGroup#186.

[GarveyJoe]

I think the three-tiered aspect approach you’ve used for host allocations (allocation is supported, device-to-device atomics/concurrency is supported, device-to-host atomics/concurrency is supported) is good. My only complaint is that the names are somewhat ambiguous; one has to read the definitions to understand the difference between usm_atomic_host_allocations and usm_concurrent_host_allocations. What do you think about working the terms “device scope” and “system scope” into the names somehow? E.g. usm_atomic_host_allocations_device_scope and usm_atomic_host_allocations_system_scope.