Improve the default value doc and logic for some state backend and checkpoint related options

Some state backend and checkpoint related options don't set the default value directly, but but they implement default value based on code. Such as:

• execution.checkpointing.tolerable-failed-checkpoints
  • https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#execution-checkpointing-tolerable-failed-checkpoints
• state.backend.type
  • https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/deployment/config/#state-backend-type

Option1

execution.checkpointing.tolerable-failed-checkpoints doesn't have default value, but CheckpointConfig#getTolerableCheckpointFailureNumber calls  configuration.getOptional(ExecutionCheckpointingOptions.TOLERABLE_FAILURE_NUMBER).orElse(0).

It means the 0 is default value of execution.checkpointing.tolerable-failed-checkpoints.

Option2

state.backend.type does't have default value, but StateBackendLoader#loadFromApplicationOrConfigOrDefaultInternal calls 

loadStateBackendFromConfig(config, classLoader, logger). When the return value is null, Flink will consider the hashmap as the default state backend.

I checked all callers of StateBackendLoader#loadStateBackendFromConfig, if we change the default value of state.backend.type to hashmap. All of them work well.

Why set the default value directly is fine?

From user side, it's clearer.

From flink developers or maintainers side, it's easy to maintain.

Proposed changes:

Adding the default value for them:

• execution.checkpointing.tolerable-failed-checkpoints: 0
• state.backend.type: hashmap

Note: this JIAR adds the default value, but the behaviour is absolutely same with old one, so it doesn't introduce any effect for users. (So the FLIP isn't necessary IIUC.)