cmd/geth, cmd/utils: log prefunded account/key in ephemeral development mode

[Arya-A-Nair]

This PR modifies the disclaimer/banner that is printed when starting up Geth in dev mode:

• if the client is spun up in ephemeral dev mode with a keystore override, the address of the first (prefunded) account is printed.
• if the client is spun up in ephemeral mode without a keystore override, the genesis allocation contains a single static prefunded EOA account. It's address and private key are logged.
• the banner is printed at the end of client initialization to make it more prominent. Previously, it was logged towards the beginning of client initialization and subsequent logging from startup filled the terminal, pushing it out of view of the user.

Other change is that we now use a static prefunded dev account instead of generating a random one when instantiating a new dev mode chain.

This is an example of what the banner looks like:

WARN [05-28|23:05:16.475] You are running Geth in --dev mode. Please note the following:
WARN [05-28|23:05:16.475] 
WARN [05-28|23:05:16.475]   1. This mode is only intended for fast, iterative development without assumptions on
WARN [05-28|23:05:16.475]      security or persistence.
WARN [05-28|23:05:16.475]   2. The database is created in memory unless specified otherwise. Therefore, shutting down
WARN [05-28|23:05:16.475]      your computer or losing power will wipe your entire block data and chain state for
WARN [05-28|23:05:16.475]      your dev environment.
WARN [05-28|23:05:16.475]   3. A random, pre-allocated developer account will be available and unlocked as
WARN [05-28|23:05:16.475]      eth.coinbase, which can be used for testing. The random dev account is temporary,
WARN [05-28|23:05:16.475]      stored on a ramdisk, and will be lost if your machine is restarted.
WARN [05-28|23:05:16.475]   4. Mining is enabled by default. However, the client will only seal blocks if transactions
WARN [05-28|23:05:16.475]      are pending in the mempool. The miner's minimum accepted gas price is 1.
WARN [05-28|23:05:16.475]   5. Networking is disabled; there is no listen-address, the maximum number of peers is set
WARN [05-28|23:05:16.475]      to 0, and discovery is disabled.
WARN [05-28|23:05:16.475] 
WARN [05-28|23:05:16.475] 
WARN [05-28|23:05:16.475]  Running in ephemeral mode.  The following account has been prefunded in the genesis:
WARN [05-28|23:05:16.475] 
WARN [05-28|23:05:16.475]        Account
WARN [05-28|23:05:16.475]        ------------------
WARN [05-28|23:05:16.475]        0x71562b71999873db5b286df957af199ec94617f7 (10^49 ETH)
WARN [05-28|23:05:16.475]  
WARN [05-28|23:05:16.475]        Private Key
WARN [05-28|23:05:16.475]        ------------------
WARN [05-28|23:05:16.475]        0xb71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291
WARN [05-28|23:05:16.475] 

closes #31796

[jwasinger]

I'll take over this PR from here.

[jwasinger]

note to self: while trying to wrap this, I ended up making a mistake that would have broken the use of custom keystore with ephemeral dev mode. I caught this before pushing, but it highlights that a test case would be useful because it's an edge case that I am only aware of because it was previously broken by accident and then fixed (in separate PRs)

[jwasinger]

One other change this PR makes is that the default prefunded developer address for ephemeral dev mode is now constant instead of being randomly generated at client startup.

It really simplifies the resulting code by being able to easily know, when printing the new dev-mode banner whether or not we're using a prefunded developer account (if we aren't ephemeral, it won't be used. if the keystore is overriden, it won't be used)

[jwasinger]

other area for test coverage:

• instantiate client in dev mode with datadir (previously-non-existent). Shut down the client, and try to start up again in dev mode, against the same datadir.

[jwasinger]

My comments turned into a bit of a stream of consciousness. I'll summarize what's going on with this PR in its current (assumed final) state in the top-level comment on this PR.

[MariusVanDerWijden]

I like the idea of having a static private key