Replace submodules with conda packages

[bonh]

I think this is already in the pipeline but I couldn't find an issue about this: I suggest that we replace the submodules of Eigen, Pybind11, and Catch2 with their conda packages.

(https://anaconda.org/conda-forge/eigen)
(https://anaconda.org/conda-forge/pybind11)
(https://anaconda.org/conda-forge/catch2)

[dannys4]

I will point out a few problems with this

1. the conda version of catch2 is guaranteed to fail with GPU and there's nothing we can do about it.
2. even when catch2 doesn't fail, it always throws a bunch of garbage warnings when linking with MParT that make no sense and, though they are ultimately meaningless because it's just from using a different compiler version than what the Catch2 folks used or something along those same lines, it's very annoying and worrying. I don't see them in the github actions, so maybe it's just my experience, but I've encountered the same compiler warnings when building against conda-installed Catch2 on three different machines in all configurations I've tried.
3. Eigen can be finicky and I've had to add/drop random flags from it when compiling. I haven't actually had this fail when using conda yet, but I think it's a possibility.
4. Not an issue so much as a genuine question-- does CMake have good support for this? It seems like we'd just have to execute a bunch of conda commands through the shell in cmake. How would we handle working in environments? I don't see a whole lot stuff out there on this, and I personally don't like either of the options of a) making a new environment without explicitly the user's permission or b) installing stuff into the current environment and just hoping that there's nothing in the environment that changes the compilation in unexpected fashion. Obviously, b) is much less of a concern, so I'd be more okay with that.
5. If someone wants to use conda installations instead, there's nothing stopping them from just doing that now (in fact, I use them for the most part). Then, they have explicit control over where they're installed and what the environment looks like.

As you may see from 5., I'm not totally against using conda installations, but I'm a little hesitant to say it should be the default. I also don't see any major issues with how it is now, though.

[bonh]

Uff, I was not aware of these issues. But didn't @mparno mention that a conda package of MparT is planned? I guess it would make sense if a conda package relies as much as possible on other conda packages.

[dannys4]

I agree with this sentiment as well. But I don't think there's anything stopping us from having the conda version of MParT relying on those packages . In fact, I'll be doing something similar with the Julia package once I can work on releasing it-- use precompiled versions of eigen, kokkos, and catch2 from the julia binary building repository when building MParT.

[mparno]

I think Danny is right here. I think we should always have the ability to build MParT from source without relying on conda installations of other packages. However, my intention for the MParT conda package is to use as many existing conda packages as possible. I think Kokkos is the only dependency we have that doesn't already have a conda package on conda-forge.

[bonh]

Okay, convinced!