Remove Dockerfile syntax from frozen features

As discussed on the maintainers mailinglist,
and during a maintainers review session;

We've recently made changes to the Dockerfile
syntax (e.g., `HEALTHCHECK`, `SHELL`), so
mentioning the Dockerfile syntax as a frozen
feature is no longer accurate.

Removing it from frozen features does NOT
automatically state an intent to make big
changes to the syntax; making changes
to the syntax are important decisions and
should never be taken lightly.

This change is just to indicate that we
can *accept* changes if they are meaningful,
and we're confident they can be made.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

ROADMAP.md

@@ -93,28 +93,7 @@ to another node in the cluster. This will be introduced in a backward compatible
 We won't accept patches expanding the surface of `docker exec`, which we intend to keep as a
 *debugging* feature, as well as being strongly dependent on the Runtime ingredient effort.
 
-## 2.2 Dockerfile syntax
-
-The Dockerfile syntax as we know it is simple, and has proven successful in supporting all our
-[official images](https://github.com/docker-library/official-images). Although this is *not* a
-definitive move, we temporarily won't accept more patches to the Dockerfile syntax for several
-reasons:
-
-  - Long term impact of syntax changes is a sensitive matter that require an amount of attention the
-    volume of Engine codebase and activity today doesn't allow us to provide.
-  - Allowing the Builder to be implemented as a separate utility consuming the Engine's API will
-    open the door for many possibilities, such as offering alternate syntaxes or DSL for existing
-    languages without cluttering the Engine's codebase.
-  - A standalone Builder will also offer the opportunity for a better dedicated group of maintainers
-    to own the Dockerfile syntax and decide collectively on the direction to give it.
-  - Our experience with official images tend to show that no new instruction or syntax expansion is
-    *strictly* necessary for the majority of use cases, and although we are aware many things are
-    still lacking for many, we cannot make it a priority yet for the above reasons.
-
-Again, this is not about saying that the Dockerfile syntax is done, it's about making choices about
-what we want to do first!
-
-## 2.3 Remote Registry Operations
+## 2.2 Remote Registry Operations
 
 A large amount of work is ongoing in the area of image distribution and provenance. This includes
 moving to the V2 Registry API and heavily refactoring the code that powers these features. The