Refactor libcuvs_c header and source locations

[robertmaynard]

In support of building a stable C interface for libcuvs I have moved all C code into a separate directory for both the headers and sources. This will make it easier to install just 'C' language headers, make it easier to apply code rules for C headers, and in the future add more CI checks for our C API.

[robertmaynard]

By moving this into a separate header it will reduce the complexity of reviewing #1348

[benfred]

Rather than put in the c headers incpp/include/cuvs/c/ - how about we create a top level c directory like we have for cpp, go, rust, python, and put the C headers and source in there rather than in the cpp/ directory? (like c/include/cuvs/neighbors/cagra.h instead of cpp/include/cuvs/c/neighbors/cagra.h )

Right now the user has to add an extra /c/ to the path when including the header files - and I'd rather avoid changing what the include path looks like .

[robertmaynard]

Rather than put in the c headers incpp/include/cuvs/c/ - how about we create a top level c directory like we have for cpp, go, rust, python, and put the C headers and source in there rather than in the cpp/ directory? (like c/include/cuvs/neighbors/cagra.h instead of cpp/include/cuvs/c/neighbors/cagra.h )

Right now the user has to add an extra /c/ to the path when including the header files - and I'd rather avoid changing what the include path looks like .

This opens us to incorrect installs of libcuvs or libcuvs_c since when we install we flatten everything to the same install location of include/cuvs/. That means we would have to either manually validate that we don't introduce any .h files under /cpp/include or use some of the tooling from package managers like conda to warn us.

The current model of the source tree layout is that the cpp, rust, go are all roots for build invcocations. If we elevate c to that level ( happy to do so ) we should also seriously consider making it a seperate build instead of a component of the cpp build.

[robertmaynard]

I am happy to try moving everything over to cuvs/c/src and cuvs/c/include while we discuss if we like that layout / side-effects

[mythrocks]

/ok to test 8afc1c1

[benfred]

thanks for these changes! I think this looks great, and I like how clean the separation is between the c and c++ code with this change -

[robertmaynard]

/merge