replace dockerfile/dockerignore with patternmatcher/ignorefile

[thaJeztah]

relates to:

• integrate frontend/dockerfile/dockerignore from BuildKit patternmatcher#1
• remove buildkit as dependency from the CLI (integrate github.com/moby/buildkit/util/appcontext) docker/cli#4457

---

vendor: github.com/moby/patternmatcher v0.6.0

• integrate frontend/dockerfile/dockerignore from buildkit

full diff: moby/patternmatcher@v0.5.0...v0.6.0

replace dockerfile/dockerignore with patternmatcher/ignorefile

The BuildKit dockerignore package was integrated in the patternmatcher
repository / module. This patch updates our uses of the BuildKit package
with its new location.

deprecate frontend/dockerfile/dockerignore

This package was moved to github.com/moby/patternmatcher/ignorefile.
Mark the alias as deprecated.

☝️ doing the deprecation in a separate commit, so that we can consider backporting the first commit to the release branch (without having to silence linters)

[tonistiigi]

I don't think we need this deprecation file

[thaJeztah]

Without it, external consumers won't discover that it was moved, and will be caught off-guard when the alias is removed, and now need to search "where the heck" it went.

[thaJeztah]

w.r.t. the deprecation message, I asked Tonis on slack if he could provide more details; let me post here;

we don’t have stability guarantees in the Go API. People will need to update their code anyway. Just extra maintenance work and inconsistencies.
buildkit should be a project where we iterate as fast as possible. If needed we should do more releases even if they are tiny instead of backports

My motivation for adding the deprecation comment is two-fold; I'd love to have these changes in with the potential to have them included in a v0.12.x patch release; I want to cut-down circular dependencies as much as possible (and as early as possible), as they currently are a blocker for some other repositories to complete the migration to Go modules.

However, moving this code means a breaking change for consumers of this code (which we "don't know who they are"). The deprecation comment should trigger linters, which helps them to migrate their code before it's actually removed, and to save them being caught off-guard when it is removed (having to try to figure out "where the h*ck that code went").

I'm not a maintainer though, so let me know if that's still a show-stopper, and if a breaking change is preferred (i.e., remove the alias) but also if that would make this patch "not qualified" for back-porting (#4170).