Add safe_block_hash to notify_forkchoice_updated

[mkalinin]

Specify CL client behaviour around safe_block_hash parameter of engine_forkchoiceUpdatedV1 function call. The PR proposes the following changes:

• Introduces safe_block_hash parameter of notify_forkhoice_updated function call
• Stubs safe_block_hash with the head_block_hash value until safe block function is implemented

Alternatively, safe_block_hash may be stubbed with 0x00..00 as introducing "safe" block tag to JSON-RPC API isn't expected within the Merge at least now, thus, safe_block_hash value doesn't matter much. Though, head_block_hash value is slightly preferred because i) most CL clients already implemented this behaviour ii) it's future compatible with the decision to deliver "safe" tag within the Merge but make it an alias to the head

[hwwhww]

I guess it doesn't matter much in using head_block_hash or the latest finalized block hash since it's just a stub?

LGTM

[djrtwo]

looks good. note, this is a no-op for client implementations that use the engine API today because this already was passed between the layers on that API

[mkalinin]

I guess it doesn't matter much in using head_block_hash or the latest finalized block hash since it's just a stub?

Stubbing with the head_block_hash has a matter because existing CL implementations are already using head_block_hash as a stub. And as @djrtwo mentioned this PR should be a no-op for implementers.