Introduce ScriptTrigger & CommandsTrigger for the JBang plugin

## Context

Part of #313. `plugin-scripts` wants every submodule to expose a `ScriptTrigger` and a `CommandsTrigger`, so a flow can be triggered whenever the underlying script/commands execution completes, with an **exit condition** deciding whether the trigger fires based on the result (e.g. only on failure).

`plugin-script-jbang` is missing both. Existing implementations in `plugin-script-go`, `plugin-script-node`, `plugin-script-python`, `plugin-script-ruby`, and `plugin-script-shell` (same package as the task classes, no nested subpackage) can be used as a reference.

## What to implement

### 1. `ScriptTrigger`

- Triggers when `io.kestra.plugin.scripts.jbang.Script` execution completes.
- Emits an event containing: command executed, arguments, env (if available), exit code, stdout/stderr (if capture enabled), and contextual metadata (execution id, namespace, flow id).

### 2. `CommandsTrigger`

- Triggers when `io.kestra.plugin.scripts.jbang.Commands` execution completes.
- Emits an event containing: commands executed (or the matched one), exit code(s), stdout/stderr if available, and contextual metadata (execution id, namespace, flow id).

## Trigger configuration requirements

Each trigger should accept at least:

- `commandPattern` (string / regex / glob)
- `argumentsPattern` (optional)
- `exitCondition` (string expression — can match on exit code, output, or a literal condition)

## Example YAML

```yaml
triggers:
- id: on_jbang_fail
type: io.kestra.plugin.scripts.jbang.ScriptTrigger
commandPattern: ".*"
exitCondition: "exitCode != 0"

triggers:
- id: on_jbang_commands
type: io.kestra.plugin.scripts.jbang.CommandsTrigger
commandPattern: ".*"
exitCondition: "exitCode == 0"
```

Start by reading the existing ScriptTrigger and CommandsTrigger implementations in plugin-script-go, plugin-script-node, plugin-script-python, plugin-script-ruby, and plugin-script-shell, then inspect the JBang Script and Commands task classes. Implement both triggers in the same package as the task classes, including the listed patterns, exit condition, execution data, and contextual metadata. Done means both trigger types support the provided YAML examples and their executions emit the required events.

Written by the indexing model from the issue text.