Add testsuite as a submodule of c2rust

[ahomescu]

This imports and runs the test suite through the main repository, mapping every commit in c2rust to an exact commit in c2rust-testsuite. Any updates to the suite have to go through the main repository, which means the suite cannot be updated underneath us anymore.

[kkysen]

Is this trying to add the testsuite to c2rust directly? If so, why not just inline it directly? That seems a lot simpler instead of having multiple levels of submodules. Putting them in the same repo also gives the important benefit of being able to make changes across both at once, which a submodule doesn't.

[ahomescu]

If so, why not just inline it directly?

We could inline it directly using git subtree, but why? This approach is simpler.

[ahomescu]

By "simpler" I mean it doesn't duplicate an entire repository (with its history and contents) in a second place.

[thedataking]

Now we have $ROOT/tests and $ROOT/testsuite which is a bit messy.

Doesn't have to be this PR but how about moving stuff under tests into tests/unittests and putting the present stuff under tests/integration or tests/testsuite? It would tuck away everything neatly under tests.

[kkysen]

We could inline it directly using git subtree, but why? This approach is simpler.

What benefit does the submodule give us, though? I'm just not sure what the motivation is. Inlining it (not as a subtree, although I don't know much about git subtrees) gives us the major benefit of PRs and commits that can span both atomically.

[kkysen]

I think there are submodules inside the c2rust-testsuite's submodules that we don't want to clone. If I'm remembering right when I tried git clone --recursive.

[ahomescu]

What benefit does the submodule give us, though?

All updates to the testsuite would have to go through the main repository (you have to update the submodule explicitly through a top-level commit), which would avoid today's problems. That would be nice to have, but not critical.

[kkysen]

What benefit does the submodule give us, though?

All updates to the testsuite would have to go through the main repository (you have to update the submodule explicitly through a top-level commit), which would avoid today's problems. That would be nice to have, but not critical.

Does that mean for every change in the testsuite repo, we then have to make a separate PR to update the submodule to the new master? That seems like a lot of extra work, if I'm understanding how it works correctly.