Extend July release

[benegee]

With Claude's help I was finally able to systematically investigate the increased number of bindings seen in #135. The reason is of course very stupid. When I decided to upgrade Clang.jl, I started the dev project from scratch and Glob.jl was updated as well. Glob.jl version 1.5.0 added a lot of features, among them vtjnash/Glob.jl#58 which added support for ** in paths. With this feature,

T8code.jl/dev/generator.jl

Line 24 in 7cc9233

glob("**/t8_*.h", include_dir) ;

becomes recursive, including all headers in any nested subfolders. I do not know why level 4 headers had been excluded previously (a86746f), but this is exactly where the additional bindings come from. I think it makes sense to include all headers when generating the bindings. It might not be a relevant part of the public API, but the symbols are exported by libt8.so anyway.

This PR therefore is an extension of the previous July release. It adds the deeply nested headers, which were excluded before.

Some comments:

• I still had to the manually copy t8_refcount.h, which is shipped erroneously in a PRIVATE_HEADER folder, see t8code July release #127 (comment).
• I had to exclude t8_dtri_to_dtet.h, which is one of the new headers. It redefines several API functions, which actually exist in libt8.so and are usable, see Update to Clang 0.19 #135
• I had to manually add const P4EST_QMAXLEVEL = 29 which is defined in some p4est header, see Update to Clang 0.19 #135
• I decided to add dev/Manifest.toml to the repo to better track how released were generated.

Finally I asked Claude to compare Libt8.jl in this PR with current main's:

Still purely additive: every one of the 849 shared functions keeps a byte-identical signature, as do all shared structs and consts. The only removals are the 5 dead t8_mat_*. Dead wrappers went 39 → 34, with none newly introduced. The t8_refcount_* / sc_refcount_* needs are all intact.

(t8_mat_* comes from another header file in PRIVATE_HEADER. I had copied it manually before, which however does not make sense)

Based on this analysis, this could be a non-breaking release.

Next steps would the actual upgrade of Clang.jl (#135) and new monthly releases.

[JoshuaLampert]

Is this ready from your side @benegee? I am currently planning some similar updates to P4est.jl and also noticed that updating Clang.jl to v0.19 changed a lot of lines in LibP4est.jl (not sure if it also added new bindings). It would be nice if you could also take a look there and help with your experience from T8code.jl.

[benegee]

Thanks @JoshuaLampert!
Yes, this is ready from my side. I am just not sure if I should rather make it a breaking release.

About P4est,jl, I'd be happy to help!

[JoshuaLampert]

LGTM!