feat: convert bech32 address into hex address in staking precompile

## Description

In the current staking precompile, it uses both bech32 and hex as inputs and outputs of each method which would confuse EVM dApps developers.

```solidity
function delegate(
address delegatorAddress,
string memory validatorAddress,
uint256 amount
) external returns (bool success);
```

There were efforts to change all addresses in the staking precompile from bech32 to hex in the past. (this pr in the evmos - https://github.com/evmos/evmos/pull/2200)

It would be good to modify this staking contract interface and lower the barrier for EVM dapps developers.

## As-Is

- using [hex address](https://github.com/cosmos/evm/blob/6e67d63098901adeb71d7de0f4e092ad8a472a64/precompiles/staking/StakingI.sol#L243-L248) for the query `validator`, while using bech32 address for [the transaction](https://github.com/cosmos/evm/blob/6e67d63098901adeb71d7de0f4e092ad8a472a64/precompiles/staking/StakingI.sol#L165-L175) `delegate`.
- this kind of mixed uses of address format potentially confuse evm ecosystem.

## To-Be

This can be solved in either way:

1. convert all the addresses in the staking contract into hex addresses
2. add hex only address function interfaces in the staking contract for backward compatibility

**Pros:**
- evm developer friendly interface
- address is much lighter than string type in solidity

**Cons:**
- different address format from cosmos ecosystem explorers and libraries such as cosmjs

Read precompiles/staking/StakingI.sol, comparing the validator query at lines 243-248 with delegate at lines 165-175. Determine which compatibility path is appropriate: converting all staking addresses to hex or adding hex-only interfaces while preserving existing calls. Done means the interface no longer requires mixed address formats and the selected compatibility behavior is covered.

Written by the indexing model from the issue text.