Cut Meshes: Change to using binary regions

[cgt3]

Calls to functions from PathIntersections should use binary_regions=true. Note the code as is running correctly since the differences in the output for non-binary regions vs binary regions is ignored in StartUpDG. See code in src/cut_cell_meshes.jl in the branch cgt3-thesis-edits for the correction.

Why binary regions?
Binary regions means every point in the Cartesian embedding domain is either included or excluded, and by extension, the regions defined by the embedded curves are either inside or outside the domain. Elements of the background mesh are assigned a 0 it they are Cartesian, a 1 if cut, and a -1 if excluded.

Non-binary regions is for applications where the embedded curves delimit areas with differing physics (i.e. a different governing PDE, forcing term, etc) and thus their enclosed regions can still be part of the simulation domain.

As of this writing PathIntersections.jl does not support non-binary regions despite it providing the interface for it. Even if/when non-binary regions are supported, our code would still remain compatible: non-binary regions assigns elements of the background mesh 0 if they are Cartesian, i=1,2,... if they are cut by the i^th curve, and -i if enclosed by the i^th curve.

StartUpDG.jl only checks if each background element's designator is <, ==, > 0 and thus remains compatible with either interface. However, once it is implemented, using non-binary regions will be more expensive than using binary regions and should be avoided to save time and memory.