Consider folding support for Dockerfiles

The VS Code 1.21 release added a new (proposed) API for folding support. The API currently includes three different "types" of folding.

export enum FoldingRangeType {
	/**
	 * Folding range for a comment
	 */
	Comment = 'comment',
	/**
	 * Folding range for a imports or includes
	 */
	Imports = 'imports',
	/**
	 * Folding range for a region (e.g. `#region`)
	 */
	Region = 'region'
}

Should folding support be added for Dockerfiles? If yes, what should be considered as something that can be folded by the user? And what "type" should they be? I think the obvious one is multiline comments but what else?

Here are some scenarios I thought of:

1. any instruction that spans multiple lines (Region type)
2. only RUN instructions that span multiple lines (Region type)
3. build stages, if you have two or more FROM instructions then every FROM that gets detected would be considered a folding region for its build stage (Region type)
4. initial set of (ARG) instructions that come before the first FROM instruction in a Dockerfile (could be Imports or Region type, I'm not sure)

If we consider both 1 and 3 then there is a problem because you end up returning two different folding regions with the same starting line. Consider the following Dockerfile:

FROM node
  AS setup
RUN /blah/blah
FROM node AS test
RUN /blah/blah

This Dockerfile would have a folding region from 1-2 (for the multiline FROM instruction) as well as 1-3 (for the setup build stage). I'm not sure how VS Code handles this right now but it doesn't feel like a great user experience. I do realize that this example is a bit contrived as I don't think anyone writes FROM instructions like that but I think it's something that needs to be considered in the implementation.

Looking forward to any feedback and comments from the vscode-docker community! Thanks!

Start with the VS Code folding API linked in the issue and compare its Comment, Imports, and Region types with Dockerfile instructions, multiline comments, and build stages. Resolve which regions should be exposed and how overlapping ranges should be handled; this issue names no repository files or test entry point, so the implementation scope and completion checks still need to be established.