[PyTorch] Update to 2.4.0, add distributed

[HGuillemet]

Included in this PR:

• Update to PyTorch 2.4.0
• Add distributed framework (backend Gloo)
• Add a minimal binding for std::chrono, needed by distributed (TBC)
• Add an adapter for intrusive_ptr, enabling transparent usage like for shared_ptr
• Add an adapter for weak_ptr, enabling transparent usage (could be moved to JavaCPP ?)
• Add an optional Maven dependency to cuda. This allows to use types defined in the cuda presets. Users calling a method of PyTroch presets using one of these types should then have the cuda presets. Which also means the cuda library of the presets will be used, and not the system one (unless the user sets org.bytedeco.javacpp.pathsFirst and their system cuda has same version than the cuda presets).
• Merge functions packages to main package
• Fix [PyTorch 2.2.2-1.5.11-SNAPSHOT] Training produces poor MNIST model on Windows #1503
• Fix [PyTorch] Training is very slow on Linux. #1504
• Fix support for OpenMP on macos

Remains to be done:

• Determine if other distributed backends are needed (MPI or UCC. NCCL is not supported on Windows yet).

[saudet]

@HGuillemet Your account doesn't already have permission to publish for org.bytedeco??

[HGuillemet]

I don't have the secrets. Anyway PR builds don't publish.

[saudet]

You should be able to publish to org.bytedeco using your own account. I'm pretty sure I gave you access a long time ago.

[saudet]

Or maybe not, what the name of your OSSRH account?

[HGuillemet]

HGuillemet. But don't bother.

[saudet]

@HGuillemet Let's just merge this and fix anything broken with the upgrade to PyTorch 2.4?

[HGuillemet]

I'm about to add a commit for 2.4.0 upgrade

[saudet]

Ok, we can do that too

[HGuillemet]

Before merging, you must decide what to do with bytedeco/javacpp#766

[HGuillemet]

Also to decide: whether adding the cuda dependency is a good thing or not.

[saudet]

An optional dependency on the presets for CUDA that only torch_cuda needs, sure, that's fine.

[saudet]

Instead of doing that, please add helper.class, chrono.class and cudnn.class to the @Platform(inherit=... list.

[HGuillemet]

Done for cuda, but what helper.class and chrono.class are you talking about ?

[saudet]

Right, JavaCPP assumes the helper classes to be in the same package as the generated classes, so let's remove that package too?

As for chrono, see bytedeco/javacpp#766 (comment)

[HGuillemet]

An optional dependency on the presets for CUDA that only torch_cuda needs, sure, that's fine.

Consider my comment on top post: the dependency will be mandatory when using CUDA. Presently, most users use their system cuda I guess, they will now have to use cuda presets.

[saudet]

Sure, that's fine, it's not a huge dependency

[HGuillemet]

@saudet please restart the jobs that failed