refactor(FormData/Serializer): Early fix for supporting async blob source

[jimmywarting]

This new FormData Serializer takes a FormData and converts it into a new Blob with other preexisting Blob parts

The benefits

• Less code
• Don't need to calculate the byte length (Content-Length) - you get it from the new blob instead
• Don't have to read the content of the File entries or keeping any of the File entry content in memory until it's necessary to read them after blob.stream() is called, hence more RAM friendly
• Still synchronous
  • Good for when you eg have to clone a Response new Response(new FormData()).clone()? but why would you? have have no idea, still a valid case?
• partially solves a blocker of async blob sources (refactor: asynchronous blob backing store #10969)

Other considerations/possible solutions:

Returning a ReadableStream or async iterator... Converting it to a blob seems to be the most easiest... Then fetch can just treat it as a any other blob and don't do any special if-that-then-do-this logic
I have used this formdata-to-blob technique in my formdata-polyfill for years by converting it into a blob since IE9 was a thing in the past

---

The old Serializer did read the content from File Entries using _byteSequence. That is no longer going to be supported once we have async blob sources that can originate from the filesystem and don't hold the data in memory

[lucacasonato]

LGTM, thanks. Nice simplification.