Improvement to Fee Recipient UX

[james-prysm]

What type of PR is this?

Feature

What does this PR do? Why is it needed?

Experimental UX improvements for fee recipient / validator registry. currently, the proposer settings update is required from the validator client either through flags --suggested-fee-recipient or --proposer-settings-file or url. this is a redundant experience for users who have set the suggested-fee-recipient on the beacon node and would like to not have to specify this again on the validator client. This pr looks to address this in the following way

1. don't periodically call the push proposer settings function in validator client if no proposer settings/suggested fee recipient etc is called
2. don't write warning logs when flags are not provided on validator client
3. remove the restriction on starting validator client without a fee recipient
4. add logs to notify the user that proposer settings/suggested fee recipient was provided.
5. setting fee recipient will only persist after 1 epoch after calling beacon node again, if the restart happens prior to this the value will not persist.
6. --enable-builder flag will add to the proposer settings file if used together and the proposer settings file has builder options empty.

related issues
#11322
#10720 - will not be addressed in this PR but a separate PR
gas_limit persistence through API is not addressed in this PR

note: extra UX improvements

• changing validator index not found logs to only be debug logs

[terencechain]

This is rather dangerous, and we shouldn't skip out on the error and just default to burn address.
The caller should be able to handle the error with a switch statement

[davnex]

This is rather dangerous, and we shouldn't skip out on the error and just default to burn address.

The caller should be able to handle the error with a switch statemen
rotsen11

[james-prysm]

I'll handle this better