Mime multipart request parsing.

#139
This implementation includes several layers of support for reading multipart request bodies.
1. The lowest level is the MultipartReader that can parse any stream minimal buffering. It gives you the headers and body of each section one at a time and then you do what you want with the body of that section (buffer, discard, write to disk, etc.).
2. The next level up supports buffering the individual bodies to memory or disk and returning you an  IEnumerable of all the sections.
3. The next level up exposes extension methods on HttpRequest to determine if this is a multipart request and to read it using the methods from level 2 above. This will also cache the results in a feature interface so they can be accessed again by later calls.
4. There is also extension method support for reading nested multipart entries.

Here is a functional sample:
https://github.com/aspnet/Entropy/commit/4e083df512b90666f65cf406eae6c7128649c7fd

None of this work is prescriptive about how you want to interpret the content. If we want to interpret it as files then we would add one additional layer that would read the content-disposition header to get the file details. However, when we get strongly typed headers that information should be more readily available anyways.
APIs are made first class when they appear in 80% of applications. Which is why Form and Files are first class. I'm not arguing that multi part should be internal but making extension methods like this seems premature because it isn't something that is used everyday. A good way to gauge would be to look at other frameworks/http stacks and see what things appear as first class methods, properties, functions etc. AFAIK this isn't usually one of them.