Add a memory space abstraction

[pratikvn]

This PR is a draft PR which showcases how a memory space abstraction would look like in Ginkgo. All the memory operations such as alloc, free and raw_copy_to's are move from the Executor to the MemorySpace class.

By default, Executors are created with separate new memory space objects thereby trying to maintain the same behaviour as before this PR. Executors can also be created with an associated memory space. In that case, with matching memory spaces, the data would not be copied.

This PR is experimental and is available for anyone who wants to discuss and play around with the code.

Please feel free to point out problems and issues with the current implementation and suggestions for improvements are welcome.

TODO

• Add documentation.
• Check whether polymorphic_object can also be completely abstracted.

Update:
Interface breaking change, See #402

[pratikvn]

Note: After thinking about this I decided that it does not really make sense to try to force this into a non-interface breaking addition. There are a couple of things that are problematic:

1. The Loggers on_* memory logging methods currently take Executor * and those will need to be updated. For a non-interface breaking addition, I can only add additional methods which take MemorySpace *, which considerably bloats the code.

2. The alloc , free and copy_from methods are in the public interface of the Executor class and hence I cannot simply move them to the MemorySpace class but will have to call the memory space methods from within the Executor methods, which kind of defeats the purpose in a certain sense.

So, I think maybe it is indeed better to wait to add this until 2.0.0. But I guess we could possibly merge this into the ginkgo-2.0.0 branch.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
65 Code Smells

41.2% Coverage
2.4% Duplication

The version of Java (1.8.0_121) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11.
Read more here

[codecov]

Codecov Report

Merging #654 into develop will decrease coverage by 0.29%.
The diff coverage is 70.00%.

@@             Coverage Diff             @@
##           develop     #654      +/-   ##
===========================================
- Coverage    92.90%   92.60%   -0.30%     
===========================================
  Files          318      320       +2     
  Lines        22360    22445      +85     
===========================================
+ Hits         20773    20785      +12     
- Misses        1587     1660      +73     

Impacted Files	Coverage Δ
core/device_hooks/cuda_hooks.cpp	30.61% <0.00%> (-24.95%)	⬇️
core/device_hooks/hip_hooks.cpp	44.11% <0.00%> (-11.44%)	⬇️
core/devices/cuda/executor.cpp	25.00% <0.00%> (-25.00%)	⬇️
core/devices/hip/executor.cpp	14.28% <0.00%> (-19.05%)	⬇️
include/ginkgo/core/base/exception.hpp	93.42% <0.00%> (-6.58%)	⬇️
include/ginkgo/core/base/exception_helpers.hpp	90.90% <ø> (ø)
include/ginkgo/core/base/types.hpp	92.59% <ø> (ø)
include/ginkgo/core/base/executor.hpp	68.18% <25.64%> (-22.56%)	⬇️
core/devices/omp/executor.cpp	77.77% <50.00%> (-22.23%)	⬇️
core/base/memory_space.cpp	83.33% <83.33%> (ø)
... and 19 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0bfbc1d...48c9e61. Read the comment docs.

[pratikvn]

To reduce the number of PR's, I will close this for now as we dont want really long standing PR's anyway. We can open another one later maybe after 2.0