Add support for dependency scope configuration (runtime vs development) in dependency-submission action

The `dependency-submission` action currently submits all dependencies to GitHub's Dependency Graph API without any `scope` information. While the underlying [GitHub Dependency Graph Gradle Plugin](https://github.com/gradle/github-dependency-graph-gradle-plugin) (in charge of actually building the dependency snapshot that's sent to the GitHub API) fully supports assigning `runtime` or `development` scopes to dependencies, the action does not expose any configuration options to enable this feature.

The Gradle plugin explicitly documents these environment variables as the way to configure dependency scopes in its [README](https://github.com/gradle/github-dependency-graph-gradle-plugin/blob/be867f1baea35e8c8fcece928c7887e9952980b6/README.md?plain=1#L68-L89):

> **Controlling the scope of dependencies in the dependency graph**
>
> The GitHub dependency graph allows a scope to be assigned to each reported dependency. The only permissible values for scope are 'runtime' and 'development'.
> [...]
> By default, no scope is assigned to dependencies in the graph. To enable scopes in the generated dependency graph,
at least one of these parameters must be configured

However, the `dependency-submission` action does not expose these parameters, meaning users cannot differentiate between production runtime dependencies and development/test dependencies in their GitHub Dependency Graph—making it harder to prioritize security alerts.

This means that options like `fail-on-scopes` in `actions/dependency-review-action` ([see here](https://github.com/actions/dependency-review-action/blob/774d14bf50b7a2e2460f9f49e25c52503ecab125/README.md?plain=1#L119)) are useless since scope information is not available in the Dependency Graph.

If scope information were to be included in Dependency Snaphots, the action would obtain alignment with GitHub's Dependency Submission API. The [`/repos/{owner}/{repo}/dependency-graph/snapshots`](https://docs.github.com/en/rest/dependency-graph/dependency-submission) endpoints supports scope, but we're not leveraging it

## Current Behavior

All dependencies are submitted without scope, regardless of whether they are runtime or development dependencies.

The action exports `DEPENDENCY_GRAPH_INCLUDE/EXCLUDE_CONFIGURATIONS` and `DEPENDENCY_GRAPH_INCLUDE/EXCLUDE_PROJECTS` environment variables ([`sources/src/dependency-graph.ts#L40-L43`](https://github.com/gradle/actions/blob/4a417b5b1a01db0b076987546b67f8de18e7d340/sources/src/dependency-graph.ts#L40-L43)), but does **not** export the scope-related variables that the Gradle plugin supports:

- `DEPENDENCY_GRAPH_RUNTIME_INCLUDE_PROJECTS`
- `DEPENDENCY_GRAPH_RUNTIME_EXCLUDE_PROJECTS`
- `DEPENDENCY_GRAPH_RUNTIME_INCLUDE_CONFIGURATIONS`
- `DEPENDENCY_GRAPH_RUNTIME_EXCLUDE_CONFIGURATIONS`

## Expected Behaviour

Users should be able to configure which dependencies are marked as `runtime` vs `development` scope, either through:
1. Explicit action inputs, or
2. Sensible defaults that work out of the box for common Gradle projects

## Workaround

Users can manually set the aforementioned environment variables when calling the action:

```yaml
- name: Generate and submit dependency graph
uses: gradle/actions/dependency-submission@v4
env:
DEPENDENCY_GRAPH_RUNTIME_INCLUDE_CONFIGURATIONS: '(compileClasspath|runtimeClasspath)'
```

This works, but is not documented and requires users to understand the underlying plugin's configuration.

## Possible solution
Expose action inputs (like `dependency-graph-runtime--projects` or `dependency-graph-runtime--configurations`. Then, export them as the environment variables the [GitHub Dependency Graph Gradle Plugin](https://github.com/gradle/github-dependency-graph-gradle-plugin) expects in [`sources/src/dependency-graph.ts#L31-L43`](https://github.com/gradle/actions/blob/4a417b5b1a01db0b076987546b67f8de18e7d340/sources/src/dependency-graph.ts#L31-L43) before calling it.

```
core.exportVariable('DEPENDENCY_GRAPH_RUNTIME_INCLUDE_PROJECTS', config.getRuntimeIncludeProjects())
core.exportVariable('DEPENDENCY_GRAPH_RUNTIME_EXCLUDE_PROJECTS', config.getRuntimeExcludeProjects())
core.exportVariable('DEPENDENCY_GRAPH_RUNTIME_INCLUDE_CONFIGURATIONS', config.getRuntimeIncludeConfigurations())
core.exportVariable('DEPENDENCY_GRAPH_RUNTIME_EXCLUDE_CONFIGURATIONS', config.getRuntimeExcludeConfigurations())
```

Sensible defaults could also be considered so the action adds the scope for the type of runtime configurations that are expected to be used at runtime.

- `(compileClasspath|runtimeClasspath)`

This would automatically mark production dependencies as runtime scope, while test and build dependencies would default to development scope.

Alternatively, the defaults could be left empty (current behaviour) to avoid breaking changes, with documentation guiding users to enable scope differentiation

## Related

- Gradle plugin scope documentation: https://github.com/gradle/github-dependency-graph-gradle-plugin#dependency-scopes
- Note in current docs acknowledging this gap: https://github.com/gradle/actions/blob/4a417b5b1a01db0b076987546b67f8de18e7d340/docs/dependency-submission.md#L267-L269

Start by reading sources/src/dependency-graph.ts around the existing configuration exports and docs/dependency-submission.md where the gap is noted. Trace how action configuration reaches the dependency-submission action, then define and document the runtime include/exclude settings before exporting the four variables expected by the Gradle plugin. Done means users can configure runtime and development scopes through the action and the behavior is documented.

Written by the indexing model from the issue text.