Decide behavior of MAX_MEM_ALLOC_SIZE and GLOBAL_MEM_SIZE allocation tests

Issue raised by #1172. The max size allocation tests (test_allocations and test_api min_max_mem_alloc_size) are designed to be flexible, but still end up imposing requirements on memory capabilities that aren't called out in the spec (e.g. by requiring that an allocation tests succeeds at some arbitrary fraction of the published memory size). Some existing vendor implementations have tuned their queries to pass these tests, but the tests as written effectively prohibit publishing numbers based on hardware capabilities (vs a 'likely to succeed' approach). The tests themselves are useful for catching memory-related bugs.

Questions:

1. Do these tests need to be relaxed to avoid spec-by-test? Is there any allocation size that should be required to succeed?
2. Current tests attempt to allocate the max size, then attempt reduced sizes down to some limit; the PR proposes reducing both starting size and final size. Current tests have advantage of ensuring the max alloc size at least fails with an appropriate error; proposed tests reflect that there's no explicit spec requirement to fail gracefully on out of memory conditions.
3. One option would be to keep the tests but allow them to be tuned by the the vendor (similar to the non-required CL_FILTER_LINEAR mode for samplers)

Start with the test_allocations and test_api min_max_mem_alloc_size tests named in the issue, then review how their current allocation limits relate to the published memory values. Resolve whether the tests should require successful allocations, graceful failure, or vendor tuning, and define the agreed behavior before updating the tests.

Written by the indexing model from the issue text.