Clean up FileWidget's behavior when too many files uploaded

@legolasbo thanks for the patch. I am about to leave for a trip but will check it out in a week or so if it still needs review.

@legolasbo, I went back and looked at a patch I had started on this issue and reoriented myself with what's going on a bit...so conceptually I favor a different approach with this, in which you #limit_validation_errors on the remove button so that the user can choose which specific images they want to drop to get in compliance with the cardinality limit. That part of the patch is straightforward but opens a rabbit hole of other brokenness in code that doesn't quite handle that case yet. Just wondering, did you initially try this approach as well and decide it wasn't viable?

I can execute the instructions depicted in #12 successfully. This is definitely better than core lacking this patch, as it gives the user a path back to submit-ability of the overall form.

Unfortunately, I'm a bit on the fence with RTBCing it, because while the "Remove Selected" button and corresponding checkboxes on the bottom row work, all the other images that were uploaded (each row besides the bottom) also have Remove buttons, but if you use these buttons they do not work for me.

FWIW, if there's a way to just remove the broken buttons that doesn't break standalone ManagedFile form elements, I would RTBC that approach. (Though I'd probably write a new issue to see if there's a way to get them working too. I still feel like there ought to be a way to just suppress the validation from halting submission...not that I've found it.)

Hate to do this, especially with the very high likelihood of RC1 happening next week, but rather than RTBCing I'm throwing my hat in the ring with an alternative approach. I wrote this issue back in July due to my failed attempts to extricate FileWidget::validateMultipleCount from the code base as part of the resolution to #2535302: Selecting too many files with JS off causes WSOD with data loss, and really wanted to see that be part of the resolution to this issue. That method is redundant with EntityForm cardinality validation, and doesn't have as nice of a UX for the conditions where it's triggered.

Workable code for removing the selected image(s) is already present, but just wasn't quite working when too many files were uploaded. I tinkered for more hours than I'll admit in search of a way to make use of the existing code, and I think I found it. My hope is this yields more maintainable code down the line -- it's a net decrease in line count.

I'll do a few iterations of patches to aid my development. This patch is going to fail at least the test that checks for the specific error text output by the (redundant and therefore removed) FileWidget::validateMultipleCount method. It is mostly just for me to see what else it breaks. It needs its own tests (hopefully @legolasbo's will be pretty much drop-in for my approach too) and should probably be refactored slightly to tighten down and document what submit handler code runs when the usual validations have been defeated, before it's really ready.

I expect this patch to pass testing, including a test for this issue direct from #21 - thanks @legolasbo, and thanks for your fix to file.module as well.

What this patch doesn't do, that I had hinted at in #24 is make changes to submission handler logic to limit what input is used (ie, don't do anything with input that hasn't been validated) when the Remove button was clicked. Maybe someone can explain how this is a security problem -- otherwise, why would there have been validations in the first place -- but on the other hand it's actually not obvious to me that it is: although you're free to change other things about the form (like totally different fields) and have them persisted to the form state when you click remove, most of those things weren't validated anyway due to the #limit_validation_errors that already applied to the Remove button, and clicking the remove button doesn't cause any data to be permanently saved to the entity to which this field is attached - the full suite of validations must still pass when the form is submitted for saving.

Anyone at NOLA who wants to help me move this forward?