API V1 suggestions

Looks like you're still maintaining this based on recent activity. I'm updating my [Hardhat plugin](https://github.com/solidstate-network/hardhat-txn-dot-xyz) for Hardhat V3, and cleaning up some of the code that integrates with your API. I think this would be a good opportunity to release an API V1, with a few changes to help with standardization. Params like `contractAddress` and a `fn` called `sendTransaction` are non-standard, and make integration more difficult.

## Example

This schema allows the query data to be passed through to the wallet essentially as-is, with just a few validations. Txn data encoding is also obviously still needed, but can be simplified by inferring the abi from the `fnSignature` parameter.

```typescript
type QueryData = {
fnSignature: string;
fnArgs?: string[];
};

type Query = {
chainId: string;
to: string;
value?: string;
data?: Data | string;
};

const q: Query = parseQueryString(...);

const { chainId, to } = q;
const value = BigInt(q.value ?? 0);

let data: string;

if (typeof q.data === 'undefined') {
data = '0x';
// display message about sending tx with no data; if value > 0, display message about native token transfer
} else if (typeof q.data === 'string') {
data = q.data;
// display message about sending arbitrary data; maybe include a warning that the txn could be malicious
} else {
const abi = generateAbi([q.data.fnSignature]);
const args = q.data.fnArgs ?? [];
data = abi.encode(q.data.fnSignature, args);
// display function name and list of parameters for user to review
}

// pass this to wallet provider
const txn = {
chainId,
to,
value,
data,
}
```

## `Query` type

### `chainId`

ID of chain on which to send transaction. Should be processed as a hex string, to match behavior of JSON-RPC (`eth_chainId`), but can support dec strings in the URL query string.

### `to`

Recipient address. No distinction between contract and EOA.

### `value`

Native token to include. Parse string as BN, default to `0n` if undefined.

### `data`

Transaction data, with a few supported formats:

- `undefined`: no data, most likely a value transfer or a call to a contract `fallback` function
- `string`: pre-encoded data, just forward as-is
- `QueryData` object: minimal ABI data required to encode a contract function call (see below)

## `QueryData` type

### `fnSignature`

Full signature of contract function, formatted like `transfer(address,uint256)`.

Could also support named parameters, like `transfer(address to, uint256 amount)`.

Both formats preclude the need for ABI lookup, and if I were maintaining this I would drop that feature completely. However, it could still be useful for looking up parameter names if they're not included.

Bare function name (`transfer`) should not be supported because function overloading makes it ambiguous.

### `fnArgs`

Array of function arguments. Default to empty array if undefined. Create an ABI using the `fnSignature` param and validate array length and contents.