Revisit interface design and performance in IntersectionShaper

[gunney1]

The work in #1436 and [Blueprint mesh support for shaping, MR TBD] and #1455 [Support Blueprint mesh in shaping] were done under some time pressure from an application. Some of the interface and potential performance issues should be discussed, examined and fixed if needed. This issue is here to collect things that came up regarding that work.

• Check whether specifying klee::Geometry format by string a problem for performance. Fix if needed.
• There are some code whose presence crashes weirdly in Docker. Running in Docker is not a requirement of the driving application, so the offending code is disabled. Find and fix the root cause.
• The method klee::Geometry::hasGeometry method may cause confusion. What does it mean for a Geometry to have or not have a "geometry"? The method actually meant whether Geometry is read in from disk. Now that Geometry can also be constructed in memory it can have a geometry even if not read in from disk.
• The code uses both host and device memory. We should ensure that we're not unnecessarily moving data between host and device.
• Move the DiscreteShape into an internal namespace, as noted by the comment in its documentation. The class isn't meant for public use and may change upon the interface revisit.
• Consider subclassing Geometry to represent the multitude of geometry specification that are currently done by multiple constructors.
• Clean up the guards in IntersectionShaper and its test codes. IntersectionShaper requires RAJA and Umpire. There are guards in too many places. They should be consolidated.
• The test codes for IntersectionShaper should be cleaned up. Without RAJA and Umpire, it doesn't really test anything, but it nevertheless builds with a non-functional IntersectionShaper, which requires detailed guards to do.