Add CMake build rules for (some) of the generator jit tests

[steven-johnson]

Amazingly, these have been TODO for ~ever. This adds two of them; registration_test and rungen_test will be added subsequently (assuming this PR works).

[steven-johnson]

Monday morning review ping

[steven-johnson]

Monday morning review ping, again

[steven-johnson]

Pingity ping ping ping

[steven-johnson]

♫ Old McDonald had a ping
Pingity pingity ping ♫

[steven-johnson]

Re-adding @alexreinking -- the reason that apps/hannk is now failing is because of the insertion of the generator "library" for cpp_stub usage... previously, adding a dep to a Generator could be done by just doing target_link_libraries(foo.generator ... ); now, that doesn't actually help, because you would need to do target_link_libraries(foo.generator_lib ... ) for it to actually work.

Ugly options:

• Add a DEPS argument to the add_halide_generator() rule. Would work, but would break existing code. (And maybe be a weird thing for CMake users? Dunno, it's all still weird to me.)
• Build the library for cpp-stub usage separately from the generator exe (ie, redundantly). This would maintain existing usage, but means that the hidden _lib target would need explicit attention from users that need to add deps to it.
• Something else? For good or ill, we can't do the JIT tests without the cpp-stub stuff (even though cpp-stub stuff is gross and awful, but we can't delete it just yet).

[steven-johnson]

Post-vacation ping to @alexreinking

[steven-johnson]

Bride of Return of Ping to @alexreinking

[alexreinking]

There's a nice...ish... way to do this in CMake 3.27 (latest) that I outlined in the review suggestions. You create an interface library that propagates the links / includes and object files (filtering out GenGen.cpp.o is 3.27+).

For now, I'd prefer to preserve existing usage since an eventual upgrade to CMake will allow us to do that anyway. Maybe only build redundantly if the cpp stubs are requested via the argument?

[alexreinking]

• Add a DEPS argument to the add_halide_generator() rule. Would work, but would break existing code. (And maybe be a weird thing for CMake users? Dunno, it's all still weird to me.)

This already exists as LINK_LIBRARIES doesn't it?

• Build the library for cpp-stub usage separately from the generator exe (ie, redundantly). This would maintain existing usage, but means that the hidden _lib target would need explicit attention from users that need to add deps to it.

I think this is the way to go given our current CMake version.

[steven-johnson]

Wow, I had forgotten about this PR. Will your upcoming CMake upgrade make any of this easier? (or at least less-bad)

[steven-johnson]

We should really clean this up and land it (otherwise we aren't getting all of our tests built + tested under CMake); what are the sticking points?

[alexreinking]

I think I'm happy with this after removing the FILTER.

[alexreinking]

QQ: why is this needed? Which files do they access?

[steven-johnson]

At this point, I don't remember. I'll remove it and see what breaks :-)

[steven-johnson]

The target_include_directories is apparently unnecessary, removing

[steven-johnson]

@alexreinking I'm not sure how to resolve the conflicts here to land this, can you take a quick look?