Naming schema is inconsistent

[satsfy]

The naming schema of corepc client and types is ad hoc. Some examples:

In client:

• derive_addresses (no optional args) and derive_addresses_multipath (with second optional arg), or
• estimate_smart_fee (no optional args) and estimate_smart_fee_with_mode (with second optional arg).

The suffix changed. One says with_<argname>, the other says <argname>.

In types:

• GetTxOutSetInfo.BlockInfo.Unspendables becomes GetTxOutSetInfoUnspendables. Could have been GetTxOutSetInfoBlockInfoUnspendables.
• GetTransaction.Details[item] becomes GetTransactionDetail. Could have been GetTransactionDetailsItem.
• GetBlock(verbose=3).Tx[Vin[Prevout]] becomes GetBlockVerboseThreePrevout. Could have been GetBlockVerboseThreeTxItemVinItemPrevout.

Observations:

• If we need to support more optional arguments, the name permutations should logically increase by N+1 methods for every new optional arg we support. Clearly not good. Otherwise, we simply don't support valid optional arguments.
• Corepc types avoid repeating themselves at the cost of potential drift.
• About verbosity, getblock uses get_block_verbose_zero/one/two/three, but getrawtransaction uses a single get_raw_transaction + get_raw_transaction_verbose.
• The same RPC is split into feels-based number of methods, such as scanblocks is three methods _start/_status/_abort, while others fold everything into one.
• signmessagewithprivkey is PrivKey in the type but privkey in the fn name while getrawaddrman is AddrMan in the type but addrman in the fn name.
• Some good conventions to keep are ScriptPubKey, for example. Codegen could generate something like DecodePsbtInputsItemWitnessUtxoScriptPubKey, notice that this struct matches several others in repo and abstracts them all into ScriptPubKey because it is consistent.

I found this problem because I'm implementing a codegen production client, and, to match the existing naming schema, it requires many exceptions for machine generated naming schema to fit the mold.

Therefore, I propose we standardize a coherent naming schema for corepc.

[satsfy]

I propose formalizing the rules to:

• Method name = snake_case of the RPC (getblockheader -> get_block_header) exactly as core names it.
• Optional args = one options struct + a single _with overload (X and X_with(opts)), instead of a named method per arg combination.
• Return type = PascalCase of the RPC (GetBlockHeader), model type reuses the same name, and a fallible model gets {Type}Error.
• Verbosity = base method is verbosity-0, higher levels are {X}_verbose_one/two/three with types {Type}VerboseZero/One/Two/Three.
• Nested types = one rule path derived like {Parent}{Field}, Item (list) and Entry (map), with structurally identical shapes collapsed into one shared type.

[tcharding]

Can we split this into two separate issues: types and client. For types I'd like to see it super uniform and overly verbose names are ok because the 'inner' types should rarely be used explicitly downstream. For client I don't really mind but I don't really want to see super verbose names. FTR the client is not intended to support every optional arg, and note that there is still a way to pass optional args through without an explicit method. As such all methods are conceptually just for ergonomics.