CryptoGetInfoResponse.AccountInfo Response

### Background

For reference the SDK team leverages the CryptoGetInfoResponse.AccountInfo to get info about accounts. Please see thread [here](CryptoGetInfoResponse.AccountInfo ) with SDK team as reference.
With modularization we have a new behavior where if an ECDSA account has a Keccak-256 alias, then a Number alias cannot be used for that account. ECDSA accounts can exist with and without a set Keccak-256 alias. As such there is a user requirement to determine which alias they should use for an ECDSA account.
With the mirror node APIs a user can lookup an account like [here](https://testnet.mirrornode.hedera.com/api/v1/accounts/0.0.6217398) and see the appropriate evm_address value which is either a Keccak-256 alias or a number alias.

However when looking at the CryptoGetInfoResponse.AccountInfo protobuf response when looking up an account evm_address is not supported as a field, and we are returning either the keccak-256 alias or the number alias in the contractAccountId field. Strictly speaking this seems to be an abuse of this field because as the definition is written this should only be returning a ContractId - not the alias of an accountID.
@ty-swirldslabs @venilinvasilev

### Acceptance Criteria

1. Add support for evm_address field to CryptoGetInfoResponse.AccountInfo protobuf response. Work with SDK team to add support in SDK response.
2. Look at behavior of contractAccountID field. Maybe adjust response behavior or adjust the definition of the field.

### Dependencies

_No response_

### Definition of Ready (DoR) Checklist

- [ ] Clear acceptance criteria
- [ ] Clear and detailed description
- [ ] Dependencies identified
- [ ] Links to documentation
- [ ] Should be completable in 2-3 Days
- [ ] Initial draft of Low-level design document
- [ ] At least high level test plan
- [ ] Groomed/Estimated

### Definition of Done (DoD) Checklist

- [ ] Acceptance Criteria complete
- [ ] No Codacy issues greater than minor (in new code)
- [ ] JavaDocs updated/created
- [ ] Code commented
- [ ] Unit tests created/updated
- [ ] 80% test code coverage (in new code)
- [ ] Happy Path and major negative cases in HAPI tests as applicable

Start by locating the CryptoGetInfoResponse.AccountInfo protobuf definition and the SDK response handling referenced in the acceptance criteria. Review how contractAccountID is currently populated for ECDSA accounts, then add and test evm_address support and resolve the contractAccountID behavior with the SDK team.

Written by the indexing model from the issue text.