[Idea] Only allow commits when no undeletable file has been deleted

Hello,

I have an idea for a feature I am missing often enough within Git (and it **needs** to be part of Git itself as it would be rather useless within third-party tools): Oftentimes, when you have submodules, you are depending on specific files being present within them, i.e. so that your Shell scripts and/or CI tools work correctly. However, especially when the submodule is under your own control, you currently have no option to tell future collaborators that deleting or renaming such a file will break things. Or even your future self, FWIW. So, what if there was a recognized attribute within the `.gitattributes` that said `files matching this path spec cannot be deleted`? The actual content of the file is irrelevant as long as it exists. I don't care how this attribute is called in the end and cannot think of any good name. My best approach was something like `depended-on-externally` or `undeletable`.

My proposed behavior is thus the following:
- Git stores the list of files from HEAD that may not be deleted somehow 
(probably best to compute it on the fly when necessary)
     - To allow for deleting a file in the same commit as removing its 
`.gitattribute` entry, the list of files that cannot be deleted depends 
on the `.gitattributes` as it should be committed.
- When you try to create a commit, all undeletable files are checked for 
if they still appear in the tree
- If files are no longer present in the tree, the commit is aborted with 
an error message telling the user something like `You are trying to 
delete the undeletable file <x>/ files <x, y, z>. Either restore 
it/them, or remove <corresponding path specs> from the '.gitattributes'`
- In particular, this means the following behavior for changes:
     - Adding a new file: Nothing to do
     - Deleted file: Checking if it can actually be deleted
     - Renamed file: Checking if another file replaced it
- No idea how to handle path specs pointing inside submodules. I'm fine 
either way:
     - Path specs going into submodules are ignored (more performant, 
plus you cannot influence them directly)
     - Path specs going into submodules are checked too (helps catch 
bugs early as an error can only happen when you update the submodule. As 
such, you'll quickly know that you just broke something)

Drawbacks of this approach:
- `git commit` will be slower. Don't know how much, probably depends on 
the implementation

Advantages:
- You can ensure that you don't accidentally break something in other 
repos (or even your own, if you have enough dependencies on your own 
filenames…)

So, what do you think?