Fix #15561 - Add a checkbox to empty protected BLOB and binary columns - #20529

Description

This adds a way to empty a BLOB or BINARY column from the insert/edit form when the column is protected by $cfg['ProtectBinary'] (the default protects BLOBs).

At the moment a protected column only shows "Binary - do not edit" and its size. You can upload a new file into a BLOB, but you cannot empty it. I added an "Empty" checkbox next to the size:

• When it is checked, saving the row runs UPDATE ... SET `col` = ''. For "Insert as new row" it inserts '' instead of copying the original content, and it skips the SELECT that would have fetched that content.
• If a file is uploaded in the same submit, the upload wins. If the Null checkbox is also checked, the column is set to NULL.
• Unprotected binary columns are unchanged, since their hex field can already be cleared by hand.

I used a checkbox rather than a JS button so that it is sent with the form, works without JavaScript, and behaves like the existing Null checkbox. Rows added with "Continue insertion" pick it up without JS changes, because the cloning code already renames every multi_edit input. The earlier attempt in #15562 only reset the file input in the browser, so the stored value never changed. This version sends a fields_empty flag that ReplaceController passes to InsertEdit through EditField.

Tests: I added cases to InsertEditTest (insert and update SQL, plus the rendered checkbox for each ProtectBinary mode) and an end-to-end case to ReplaceControllerTest that expects the exact UPDATE query. The new tests fail without the change and pass with it, and the full unit suite passes. I also added a ChangeLog entry and a sentence to the ProtectBinary docs, and bumped the phpstan/psalm baseline counts for the new line in ReplaceController, which follows the same pattern as the lines around it.

Fixes #15561

Before submitting pull request, please review the following checklist:

• Make sure you have read our CONTRIBUTING.md document.
• Make sure you are making a pull request against the correct branch. For example, for bug fixes in a released version use the corresponding QA branch and for new features use the master branch. If you have a doubt, you can ask as a comment in the bug report or on the mailing list.
• Every commit has proper Signed-off-by line as described in our DCO. This ensures that the work you're submitting is your own creation.
• Every commit has a descriptive commit message.
• Every commit is needed on its own, if you have just minor fixes to previous commits, you can squash them.
• Any new functionality is covered by tests.