Runtime config layering cannot reset `epoch_data` or `fork` fields after they are set

[mrmr1993]

The runtime config currently uses the absence of a field to communicate that the values from the 'existing' configuration should be applied, encoded in OCaml as options. However, in the case of the epoch_data and fork fields, we also treat this option as having semantic meaning: its presence indicates that we want to override the default behaviour of using the genesis configuration at the start of the network. The interplay of these two features means that we can never 'turn off' either the fork field or the epoch_data field once they are set.

This is particularly problematic when the Mina binary is run from a debian package compiled with a config file containing these fields, because the Mina codebase is configured to load a config file from the debian path before any other config files, and without the ability to override this. Concretely, we have seen that switching CI from using 'berkeley' builds to 'devnet' builds in develop caused the rosetta integration tests to fail, because the epoch ledger differs from the one intended by the setup of the test.

There's one version of the fix -- using an option option to distinguish the semantic presence / absence from the configuration presence / absence -- in PR #16549, applied to the rosetta integration tests. However, it's not clear that this is a good way to fix this issue, and it's still hard to discover that this is an issue with those build by default, let alone to discover the right way to fix it.