The three data-driver dispatch sites (`encode_input_fn`, `decode_input_fn`,
`decode_output_fn`) share the same runtime path for functions marked
`is_custom`: when no handler is registered for the relevant role, the
match arm returns `Error::Unsupported`. Previously all three sites
emitted an identical `"custom handler required: {fn_name}"` message,
leaving the user to figure out which of the three roles they'd missed
and what signature the replacement needed.

The three sites now share a `missing_handler_arm` helper that pulls the
role name and canonical handler signature from the per-role helpers
introduced in the previous commit. Each site produces:

    missing <role> handler for `<fn>`; expected handler signature: <sig>

A user seeing this at runtime can identify both which role they
missed and the exact shape of the handler they need to register —
no trawling through macro-generated code required.

Custom data-driver handlers are spliced verbatim from the contract
module into the generated `data_driver` submodule — but the submodule
only preluded `alloc::{format, string::String, vec::Vec}`, nothing from
the user's outer `use` items. A handler written with idiomatic short
paths would fail to compile after expansion even though the validator
accepted it:

    use dusk_data_driver::{Error, JsonValue};
    #[contract(decode_output = "get_value")]
    fn decode_value(bytes: &[u8]) -> Result<JsonValue, Error> { … }
    // → error[E0425]: cannot find type `JsonValue` in this scope

Re-emit the contract module's `use` items inside the generated
submodule so each spliced handler sees the same imports it did at its
original site — signature *and* body. A handler body like
`.map_err(Error::from)` now resolves just as it did in the outer
module.

Only imports a handler actually references are carried over, detected
by scanning each handler's tokens for identifier appearances. This
keeps contract-only imports (e.g. `types::Ownable` gated behind the
`abi` feature in the test-contract) from leaking into the data-driver
build, where their feature gate wouldn't be satisfied.

The submodule scaffolding drops its `use alloc::{format, string::String,
vec::Vec};` prelude and inlines the fully-qualified paths at their use
sites instead, so a user-land `use alloc::vec::Vec;` in the contract
module doesn't collide with a preluded `Vec` in the submodule.

A `compile-pass-short-paths` trybuild fixture and a
`short_paths_compile_pass` integration test pin the round-trip: a
contract with short-path handlers must round-trip through the macro
and compile. This is the specific failure mode Defect 3 exposed —
validator-only coverage missed it precisely because the splicer was
silently broken.

…overage

The previous canonical-path signatures (`alloc::vec::Vec<u8>`,
`dusk_data_driver::Error`, `dusk_data_driver::JsonValue`) side-stepped
the re-emit pipeline — the short paths are the idiomatic Rust a user
would actually write after a `use`, and the only way to catch a
regression in handler-import re-emit is to exercise that form.

`Vec`, `Error`, and `JsonValue` are now imported at the top of the
contract module, gated on the `data-driver` feature (no contract-side
code references the short names, so the gate keeps the contract build
warning-free). The `#[contract]` macro detects which imports handlers
reference and splices only those into the generated `data_driver`
submodule.