[FEA] Deduplicate CUDA UDF sources in the URL log transforms example

[lamarrr]

Is your feature request related to a problem? Please describe.

The URL log transforms example introduced in
#23173 maintains two copies of its CUDA UDF logic:

• cpp/examples/string_transforms/url_logs/fragments.cu contains the parser and the sizing and
  output entry points used to build the precompiled LTO fragments.
• cpp/examples/string_transforms/url_logs/transforms.cpp repeats that logic in raw string literals
  for the CUDA-source JIT path.

This duplication can drift as the example evolves. It also makes the CUDA-source path harder to
read and edit because the implementation is embedded in C++ strings instead of ordinary CUDA files
with normal syntax highlighting and tooling.

The current UDF interface requires CUDA-source UDFs to be self-contained and discovers the first
function in the supplied source. It does not yet let this example provide shared headers or select
an explicit entry point. Consequently, removing the duplication should follow the modular UDF work
tracked in #23565.

Describe the solution you'd like

After #23565 provides modular UDFs, reorganize the example so its CUDA implementation has a single
source of truth. Keep the shared URL parsing code and the sizing and output operations in ordinary
CUDA source/header files, then use those same sources for both the CUDA-source JIT and precompiled
LTO paths.

The example should use the modular UDF interface to provide any shared headers or fragments and to
select the sizing or output entry point explicitly. A modest compile-time or runtime cost is
acceptable: readability and demonstrating the intended modular UDF workflow are more important for
this example.

Acceptance criteria:

• The URL parser, sizing operation, and output operation are each defined in only one place.
• The CUDA-source JIT and precompiled LTO modes consume the same source implementation.
• The UDF implementation remains in normal CUDA source/header files so editors and source-analysis
  tools can understand it.
• The example continues to demonstrate both compilation modes and produces equivalent results in
  each mode.
• Relevant example tests, build configuration, and documentation are updated.

Describe alternatives you've considered

• Keep the embedded raw strings synchronized with fragments.cu. This preserves the current APIs
  but retains the maintenance and readability problems.
• Generate embedded strings from the CUDA source during the build. This could remove textual
  duplication, but it would add example-specific build machinery instead of demonstrating the
  reusable modular UDF interface.
• Split the entry points before modular UDF support is available. The current CUDA-source parser and
  header limitations would still prevent the example from cleanly sharing the parser implementation.

Additional context

• Original review concern:
  [FEA] Multi-String Output & LTO Transform Examples #23173 (comment)
• Follow-up requesting this issue:
  [FEA] Multi-String Output & LTO Transform Examples #23173 (comment)
• Prerequisite modular UDF infrastructure:
  [FEA] Support modular UDFs with explicit entry points, headers, and multiple fragments #23565