chore: only build _ext and kernels

[agoose77]

Right now, we install three libraries: _ext, libawkward, libawkward-cpu-kernels, and build some additional static variants.

We didn't change this when splitting out awkward-cpp, because I didn't want to rock the boat any more. Since becoming more well versed with CMake's nuances, I'm confident that we can remove the leftover baggage.

This PR keeps the separate libawkward and _ext libraries (because it doesn't appear trivial to merge them), but drops the static libraries.

[codecov]

Codecov Report

Merging #2813 (05ee4a2) into main (9d874a0) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

[agoose77]

@jpivarski this PR fails on Windows. The error message in the CI indicates that the copy-assignment constructor for GrowableBuffer is being called by std::vector, but this constructor is implicitly deleted if one defines a move-assignment constructor.

I'm not sure why it's suddenly an issue. It's possible that the CI toolchain bumped MSVC at the same time that I wrote this PR, but I doubt it; in this PR I also added an EXPORT_SYMBOL for the FromJsonObjectSchema class, which has std::vector<GrowableBuffer<T>> members. That seems like causative.

This raises the following questions for me:

1. Why does GCC not complain if MSVC does?
2. Why does the standard not imply that the V in std::vector<V> needs to be copy-assignable (and copy-constructible?)? It used to in C++11, but seems to relax the rule for C++17+ (see "Template parameters" in https://en.cppreference.com/w/cpp/container/vector).
3. Is it reasonable to add a copy-assignment constructor to GrowableBuffer? It seems to me like we really don't want that.

I'll keep digging.

[agoose77]

Well, that (05ee4a2) worked! I'm not entirely clear on why this became an error once I exported this class, but it seems that the emission of the default copy-assignment constructor leads to the attempted copy-assignment of the GrowableBuffer.

Clearly, we don't want that, so 05ee4a2 deletes the top-level copy-assignment (rather than implementing it)

[jpivarski]

Reducing the number of shared libraries to two (one is the Python module and the other is dlopened through ctypes) is ideal.

However, this PR doesn't change awkward-cpp/src/awkward_cpp/cpu_kernels.py to look for kernels in libawkward.so. It's odd that it passes tests: how does the kernel dispatch find the CPU kernels?

Are the tests picking up a cached version of awkward-cpp?