Formatter plugins

[josevalim]

This PR adds formatter plugins which customizes how the formatter behaves.
Plugins must implement the Mix.Tasks.Format behaviour. For example, imagine
that your project uses Markdown in two distinct ways: via a custom ~M sigil and
via files with the .md and .markdown extensions. A custom plugin would look
like this:

    defmodule MixMarkdownFormatter do
      @behaviour Mix.Tasks.Format

      def features(_opts) do
        [sigils: [:M], extensions: [".md", ".markdown"]]
      end

      def format(contents, opts) do
        # logic that formats markdown
      end
    end

Now any application can use your formatter as follows:

    # .formatters.exs
    [
      # Define the desired plugins
      plugins: [MixMarkdownFormatter],
      # Remember to update the inputs list to include the new extensions
      inputs: ["{mix,.formatter}.exs", "{config,lib,test}/**/*.{ex,exs}", "posts/*.{md,markdown}"]
    ]

Remember that, when running the formatter with plugins, you must make
sure that your dependencies and your application has been been compiled,
so the relevant plugin code can be loaded. Otherwise a warning is logged.

This can be extremely useful for projects like Phoenix LiveView and Surface,
as they can now directly hook into Elixir's formatter.

[paulstatezny]

On behalf of the entire Surface community, a big thank you! This is going to scratch a common itch. 🙂

[fertapric]

What do you think about inputs, sources, locations, or identifiers as a replacement for features? For some reason, the term "feature" does not feel right to me 🙂

[josevalim]

I am not a big fan of features but I don't think any of the other ones make it justice. I thought maybe call it plugin, but I don't think it is better either. :(

[fertapric]

Oh! It could be plug_in.

Another alternative is to split features in two, sigils and extensions, but not a big fan of that option either :(

[fertapric]

Is this required? It seems the list of plugins is already validated in eval_deps_and_subdirectories, and not checking that here could be a perf improvement 🚀

[josevalim]

They are validated BUT they are still kept because we only validate it when .formatter.exs is loaded but then the result of .formatter.exs is cached. So we need to look at the cached result and see if they have been loaded post caching or not.

[fertapric]

What do you think about moving all this logic to a new function, like validate_formatter_opts or similar?

[fertapric]

Why are dep builds no longer pruned? Performance?

[josevalim]

The commit message has some context but this is not necessary anymore. before we loaded everything in _build/ENV/lib/*/ebin but now we only load your deps, so we never load something we should not.

[josevalim]

💚 💙 💜 💛 ❤️