[FEA] Default scalar arguments for pylibcudf APIs

Some `libcudf` APIs have default scalar arguments, such as [cudf::strings::capitalize](https://docs.rapids.ai/api/libcudf/stable/group__strings__case#ga92d98733aa0f694f12ef8aa4ada2ca02). `pylibcudf` does its best to remain faithful to the `libcudf` API where technically possible, meaning we should aspire to a cython API like

```python
pylibcudf.strings.capitalize(input: Column, delimiters=Scalar(""))
```

Where `Scalar` refers to a `pylibcudf.scalar.Scalar` object. However as of right now there's not an explicit mechanism for constructing `Scalar` objects from anything other than `unique_ptr[scalar]` results that are [produced as the result of calling libcudf APIs](https://github.com/rapidsai/cudf/blob/branch-24.06/python/cudf/cudf/_lib/pylibcudf/scalar.pyx#L50). In fact there's a [note](https://github.com/rapidsai/cudf/blob/branch-24.06/python/cudf/cudf/_lib/pylibcudf/scalar.pyx#L33) discouraging constructing `Scalar`s from the python side using the `Scalar` constructor at least.

One way of implementing this is to wrap the `libcudf` [scalar_factories](https://docs.rapids.ai/api/libcudf/stable/group__scalar__factories#ga910858190bf158fce6adfba4cd0cfb43) API and expose one that can produce `Scalar` we can use as a cython default, either through the `Scalar` constructor or by some other means. However I'm not sure this is the right approach and wanted to gather feedback.

There's some issues in general that I can forsee could be important with any approach, such as making sure that we don't cause a HTOD copy when we import `pylibcudf` for the purposes of making a default argument.

cc @vyasr