i18n: Allow files with a subset of translations

## Issue

Right now the i18n support in Decap will create a file for every enabled locale even if no data was entered for this locale. This can be undesirable when the user would like to fallback to the default locale if content is not available in the user locale (or if translation will be done later). You can see the effects of this issue mentioned here: https://github.com/decaporg/decap-cms/issues/4480#issuecomment-947546677.

Example: if the user creates a new page and enters the content in the default locale (en), but leaves one of the other locales blank (es) the CMS will still commit a new-page.en.md and new-page.es.md. This means that new-page.es.md may show up on index pages and as a linked translation even though it's a blank file with just header data.

## Proposed Solution

I suggest that we add a boolean configuration flag that would require manually enabling a translation. It would default to true to keep the existing behavior and keep backwards compatibility.

```
# config.yml
i18n:
save_all_locales_by_default: false
```
This config flag could trigger an updated UI element that would require the content editor to enable a translation. If the translation is enabled, the translated file will be saved. If not, no translated file will be created:


## Other Solutions

I have also thought about discarding the translation if certain fields are empty (for example, no body) - but this seems more likely to break workflows. Thoughts?

## Final Thoughts

I am interested in cooperating on a PR to help implement a feature to resolve this issue, but I would appreciate some feedback on the architecture before I begin writing code :-)

Start with the i18n configuration in config.yml and trace how locale files are created and how the content editor represents enabled translations. Define the behavior for save_all_locales_by_default: false, including the UI state and fallback case, then add coverage for saving a subset of locales. No source files or tests are named in the issue, and the architecture still needs discussion.

Written by the indexing model from the issue text.