Improve documentation when multiple error conditions produce the same error code

[bashbaug]

Originally posted by @bashbaug in #1319 (review)

Should our best practice in general be to describe separate error conditions like these using sub-bullets? I agree this makes it easier to separate the different error conditions.

We could also replicate the name of the error. I don't think we do this anywhere currently today, but this would be a bit more concise (one fewer line) and a bit friendlier when copy-pasting. Example:

* `CL_INVALID_ARG_SIZE` if if _arg_size_ does not match the size of the data type for an argument that is not a memory object.
* `CL_INVALID_ARG_SIZE` if the argument is a memory object and _arg_size_ != `sizeof(cl_mem)`.

I don't mind making this change "globally" if we think this is the right thing to do.

[kpet]

I agree that separating error conditions using sub-bullets would improve the readability of the spec. I'm a bit less sure about repeating the name of the error code though. It's nice to have a convention that guarantees all the cases for a given error code are in the same place.

[bashbaug]

If we did replicate the name of the error code then I think we should still keep the error codes "sorted", so all of the conditions for a given error code would still sit together in the same place in the spec.

I had a look and we actually do this in a few places in the spec already. Have a look at the error conditions for clCreateContext, specifically for CL_INVALID_VALUE:

* CL_INVALID_VALUE if devices is NULL.
* CL_INVALID_VALUE if num_devices is equal to zero.
* CL_INVALID_VALUE if pfn_notify is NULL but user_data is not NULL.