Consider switching `serialize`/`serializeArray` to FormData

BTW, I've been thinking about using FormData here. We'd get all that filtering we're doing out of the box. There are a few issues, though:

1. valHooks would be skipped. Now, outside of IE we now only have them for multi-select and FormData already handles multi-select identically as we do. Therefore, it's mostly about hooks defined by userland code, plugins, etc. I'm not sure how common are those, but we could re-evaluate for 5.0.
2. FormData works nicely on forms, but .serialize() can also be called on a collection of form elements, even if they're not lying in a form. I wish we didn't do this, serialization should always happen on the form level, but we do support it. I wonder how common such usage is compared to calling .serialize() on a form, but I wouldn't be surprised if it's common.

Originally posted by @mgol in #5245

To add to the above, during the team discussion @gibson042 suggested we may still try to do a version of it in 4.x by:

1. Adding temporary form props to individual elements so that FormData has a temporary form to work with.
2. Applying valHooks after FormData usage by finding elements with matching names and running the valHooks.

Begin with the existing serialize/serializeArray behavior and the FormData and valHooks constraints described here. Check both form collections and standalone form elements, including multi-select handling; done means a compatible approach has been established for these cases and userland hooks.