ReservePolicies not independent from CreationPolicies

[Flamefire]

The CudaSetLimits policy could never be used with e.g. the Scatter creation policy which would lead to undefined behaviour. The reason is, that this ReservePolicy returns a NULL pointer but the creation policy expects a pointer to valid memory of the given size.

The Scatter policy should at least check, if the given pointer is non-NULL (which also helps #110) and it should be checked, if the creation and reserve policies should be merged and/or the CudaSetLimits policy removed to avoid these kind of pitfalls.

[slizzered]

For the NULL-check: sounds very reasonable, PR coming soon.

For the discussion about the policies:
Unfortunately, not all policies are really compatible with each other. The problem is even more visible when dealing with the CUDA default allocator, since it doesn't expose/use things like a heap-pointer.

The solution might be a combination of extensive policy documentation and better constraints checking that enforces all the CUDA default allocator-specific policies to be used together. The constraints checking system itself is not really equipped to deal with groups of policies ("CudaSetLimits may not be used with any other CreationPolicy), so the temporary fix will be pretty ugly.

[Flamefire]

Well what I mean: If the CudaSetLimits policy can only be used with the OldAlloc policy and the SimpleCudaMalloc can only be used with Scatter then those should be merged.
In the current codebase I can't find any other policies but I don't know if there are/could be more usefull combinations.

[ax3l]

For the NULL-check: sounds very reasonable, PR coming soon.

can you please split the thread and open a new issue for the "bug"/safety feature aka NULL check? (for 2.2.1crp)

[Flamefire]

Actually this cannot be split. The bug/safety feature is a work-around for the problem described here. The issue IS that the policies cannot be combined freely as suggested by the syntax.

However one can consider the missing null check in the scatter policy as a bug, so I'll open that as an issue: #115