Namespace support for `nomadService(s)`

When using the `nomadService` or `nomadServices` functions, only services from the default namespace are returned. It would be nice if we could support querying services from other namespaces (or even all namespaces via `*`).

The `nomadVar` family of functions all already support namespaces using the following syntax: `nomadVar "path/to/variable@namespace.region"`. `nomadService` supports a similar format like `nomadService "tag=value.service_name@region"`.

## Possible solutions

1. Ideally we could extend the nomad service query syntax to match the one of `nomadVar` and get `"tag=value.service_name@namespace.region"`. However, that would break backwards compatibility because right now the region is assumed to appear right after the `@`. Changing the regex to assume that `@x` would be a region `x` and `@x.y` would be namespace `x` and region `y` would break existing setups, because regions may contain `.`, so we can't assume anything before the `.` is a namespace.
2. We could add two new functions with the same functionality as `nomadService` and `nomadServices`, but with support for namespaces. Those could use an updated query syntax matching the one of `nomadVar`.
3. Since the service name can't contain a `.`, we could use a syntax like `service_name.namespace@region`. This is still confusing when seen side-by-side with a `nomadVar` invocation.
4. Use a different separator than `@` and `.` for declaring the namespace.
5. We could swap namespace and region to keep the backwards compatibility, but that is strange when seen side by side with a `nomadVar` invocation (`nomadVar "var@namespace.region"` vs `nomadService "service@region.namespace"`).
6. The namespace could be passed as an additional (optional) parameter to the `nomadService` and `nomadServices` functions:
- `nomadServices` currently takes 0 or 1 parameters. We could add an optional second parameter, e.g. `nomadServices "region" "namespace"`.
- `nomadService` has two possible ways of invocation, either with 1 or 3 parameters. Adding an additional optional namespace parameter to each of those overloads would be possible without any ambiguities.

I think breaking backward compatibility is out of the question, so `1.` is out. I'm also not a big fan of the _almost the same as `nomadVar` but not quite_ syntaxes (i.e. `3.`, `4.` and `5.`). `6.` would be possible but would lead to further deviation from `nomadVar`, so my preferred solution right now would be `2.`.

I'd be happy to write up a PR once there's a consensus regarding the route to take.

## Related Issues

hashicorp/nomad#14177