Option to skip formatting specific sections

[kstrafe]

rustfmt::skip for sections of code

I would like rustfmt to support marking a section of code for skipping without using scopes and #![feature(stmt_expr_attributes)]., for instance on a set of mod X; or use X;. These would not be possible to skip using {} or wrapping inside #[rustfmt::skip] mod { ... } as this would be inconvenient to the readability of the code.

format_generated_files is insufficient here, since the file in question has both generated and non-generated code.

Example use-case

With python-cog it's possible to define comments in source files that generate Rust code. It's similar to a macro, but it leaves the generated code as well as the generator in place. Here's an example:

// cog-begin
// # This is python code using a python module that's defined in a crate which generates some code. 
// my_custom_python_module.generate_imports_of_submodules()
// cog-middle
// From middle-to-end we have generated code.
mod sub_mod1;
mod sub_mod2;
...
use self::sub_mod1::SubMod1;
use self::sub_mod2::SubMod2;
...
// cog-end

In the above case, the function generate_imports_of_submodules takes the current module and imports all submodules, adding use clauses for each submodule which are assumed to have a public type with an equivalent PascalCase name as the submodule itself.

This feature would not be limited to just module imports and use code, but also to generated sets of variable assignments, and potentially other cases such as generating a bunch of function definitions. The latter case is however easier to deal with by wrapping into a module with #[rustfmt::skip].

Possible solutions

1. In the above example it would be useful to be able to tell rustfmt that anything between cog-middle and cog-end is not to be formatted. The generator could spit out a tag like // rustfmt::skip_begin and // rustfmt::skip_end to mark this.

2. Another option is to add a rustfmt.toml option to define these markers to coincide with a specific comment string, such as skip_markers = [{ begin = "cog-begin", end = "cog-end"}], which prevents us from having to add additional markers to mark the section. In this case an array of { begin = ..., end = ... } to allow multiple such marker pairs to exist.

Performance impacts

Solution 2 is probably not going to be kind to performance if there are many such markers as we'll need to check each comment line for all begin markers, whereas solution 1 requires a bit more code generation, but only marginally so. I don't believe a crate would have a large list of markers, so solution 2 might be feasible. Otherwise, both solutions can be implemented in parallel allowing the user to use whatever is most convenient for them.