Simplify auto preprocessing

[kaisermann]

Currently, the auto mode is a single preprocessor that calls the necessary transformers given a certain svelte file. I've been wanting to refactor it for quite some time; the code feels convoluted, there are some hacky workarounds for handling options overrides, for enqueueing more than one transformer and for much more. Scenarios where babel or postcss are needed alongside some other language, like TS or SCSS, are basically hard-coded. My initial thoughts were to implement some kind of "queue" mechanism, so we could streamline the code a bit.

However, that brings me to my current way of thinking that is: we already have a queue mechanism, the one the svelte.preprocess API provides. The core of svelte-preprocess was born in 2018 when Svelte didn't have support for a queue of preprocessors yet (I may be wrong here 😅). Since we already have each transformer as a standalone preprocessor (src/processors), we could enqueue all of them in the appropriate order (babel and postcss at the end i.e). This would left the auto mode only responsible for setting default options, turning on/off settings etc.

If I'm not forgetting something and we move forward with this idea, this can be implemented in three ways:

1. sveltePreprocess() returns the array of preprocessors with the appropriate options set. This is a breaking change for people who use svelte-preprocess inside an array of preprocessors already.

// svelte.config.js
export default {
-  preprocess: [someOtherPreprocessor(), sveltePreprocess()]
+  preprocess: [someOtherPreprocessor(), ...sveltePreprocess()]
}

However, for the common use-case this shouldn't require any refactor:

// svelte.config.js
export default {
  preprocess: sveltePreprocess() // returns an array of preprocessors now, instead of a single one
}

2. sveltePreprocess() will execute svelte.preprocess inside of itself. This isn't a breaking-change and not completely novel, but it's strange nevertheless.

3. Wait for the Preprocess API RFC to go through and see what we can do after that.