Have .dockerignore support Dockerfile/.dockerignore

If .dockerignore mentions either then the client will send them to the
daemon but the daemon will erase them after the Dockerfile has been parsed
to simulate them never being sent in the first place.

Closes #8330

Signed-off-by: Doug Davis <dug@us.ibm.com>
I want to make sure I understand what you're looking for....
- a common .dockerignore reader util that the client and daemon both use makes sense
- but are you suggesting that all of the .dockerignore processing be done on the daemon-side as well and we look to remove all files from the build context and not just Dockerfile & .dockerignore?

My understanding is that the HTTP body of the "POST /build" _is_ the build context, which seems like it should be "post .dockerignore" processing - because .dockerignore is really _just_ a client-side concept.  The docs talk about .dockerignore listing the files that are excluded from the context, and the first thing the docker client does is "send the context" - not "send a set of files that are a superset of the context". And its just a Docker client concept, not necessarily a concept that all users of the REST API will support or even care about. Of course, we're tweaking that notion a bit in this case due to the need for the daemon to have the Dockerfile no matter what but we can't avoid that.  Too bad the Dockerfile isn't passed to the daemon separately from the build context then we'd avoid all of this and would actually be my preferred way to solve this - but that's a much bigger change. 

So, I'm not comfortable with the daemon blindly processing the .dockerignore again when that might not have been what the client wanted. They should have already done all of the "exclusion" processing they wanted by not including the files in the POST /build body in the first place otherwise its like they're saying "here's my build context, but I didn't really mean it".  

If we really want to head down this path I think we'd need to add a new flag so the client could explicitly ask for the daemon modify their build context (again).  But at that point I wonder if its worth the complexity when all we need (right now) is to remove the Dockerfile. Do you guys think there will be other special cases like we're seeing with Dockerfile?  I'm leaning towards thinking this is just a one-time edge-case.