* fix(jsonrpc): accept "input" as alias for "data" in call args

Closes #6517.

JSON-RPC requests using the execution-apis field name `input` were
rejected with UnrecognizedPropertyException, blocking spec-compliant
clients -- notably go-ethereum's ethclient since
ethereum/go-ethereum#28078, which only emits `input`.

CallArguments and BuildArguments now declare both fields. A new
resolveData() does pure precedence resolution -- `input` wins over
`data` -- mirroring go-ethereum's TransactionArgs.data(). Five call
sites in TronJsonRpcImpl use the resolver instead of getData(). The
verb-prefix name (not getXxx) keeps Jackson and FastJSON's JavaBean
introspection from picking the method up as a `resolveData` wire
property; two serialisation tests pin this as a regression guard.

Hex validation is mode-driven via JsonRpcApiUtil.requireValidHex
(HexMode.STRICT / HexMode.LENIENT):

- `input` (new field) is STRICT: follows the execution-apis BYTES
  schema -- requires `0x` prefix and even length; "" is accepted as
  empty bytes per geth's hexutil.Bytes.UnmarshalText.
- `data` retains LENIENT parsing via ByteArray.fromHexString for
  backward compatibility with existing callers (e.g.
  BuildTransactionTest.testCreateSmartContract uses bare-hex
  bytecode).

Conflict between `input` and `data` (both set, not equal) is
detected on the build path at BuildArguments.getContractType(),
mirroring geth's data() / setDefaults split. The error message
matches go-ethereum's setDefaults wording verbatim. Comparison is
byte-level so case differences are not flagged. The query path
(CallArguments.resolveData()) stays lenient -- input wins silently.

Tested by 52 unit tests including Jackson/FastJSON serialisation
safety guards; BuildTransactionTest.testCreateSmartContract still
passes; checkstyle clean.

* refactor(jsonrpc): extract conflict error message to constant

Hoist the input/data conflict error string in BuildArguments to a
private static final field CONFLICT_ERR_MSG, replacing the inline
literal in validateCallDataConflict.

The wording mirrors go-ethereum's setDefaults verbatim and is a
cross-project contract — external EVM tooling may pattern-match the
string. The constant's javadoc records this so future refactors do
not drift from the geth wording.