Update or remove the non-OO join APIs to account for algorithm selection

Historically libcudf has exposed both [object-oriented](https://github.com/rapidsai/cudf/blob/branch-25.08/cpp/include/cudf/join/hash_join.hpp) and [functional](https://github.com/rapidsai/cudf/blob/branch-25.08/cpp/include/cudf/join/join.hpp) interfaces to hash joins. More recently, we have begun work on [sort-merge](https://github.com/rapidsai/cudf/issues/18533) joins, a completely different merge algorithm that has performance benefits in some cases. [The current implementations of the sort-merge join](https://github.com/rapidsai/cudf/blob/d4961e1df7807fbacb1cfd49394cb4b8508d9a82/cpp/include/cudf/join/sort_merge_join.hpp) also include OO and functional APIs.

In general, the object-oriented APIs are the best choice for peak performance and fine-grained control because they allow reuse of the data structures produced as part of running the join. The existing functional join APIs are also named in somewhat confusing ways for legacy reasons (the original APIs were created when we only had hash joins). https://github.com/rapidsai/cudf/issues/19172 proposed exposing algorithm selection via those join APIs, avoiding the need for two different functional APIs corresponding to different underlying algorithms.

I think that we have two potential paths forward to improve the API.
1. Modify the existing join APIs to add algorithm selection via an enum (and removing the extra functional APIs introduced for sort-merge joins).
2. Removing the functional APIs altogether and encourage exclusive usage of the object-oriented APIs.