Keep preprocessors/backends execution order deterministic

[HollowMan6]

There's a regression caused by recent refactor work, as it used to execute preprocessors/backends in a deterministic way, but now this is not the case, which causes trouble when some backends implicitly depend on the result from another backend and happen to work (e.g. mdbook-pdf). The root cause is that a HashMap has no order, so this PR switches this into BTreeMap instead.

[ehuss]

Just for clarification, this doesn't appear to preserve the order in book.toml (I don't think it did in the past, either, though it was alphabetical). I'm fine with merging this, but I just wanted to verify we're both understanding this correctly.

I'm wondering, if a renderer requires a certain order if it would make sense to instead have an explicit order like preprocessors do?

[HollowMan6]

Just for clarification, this doesn't appear to preserve the order in book.toml (I don't think it did in the past, either, though it was alphabetical). I'm fine with merging this, but I just wanted to verify we're both understanding this correctly.

Ah...😅 To be honest, I didn't really check the source code in the past until today I found mdbook-pdf is broken, and I imagined it used to preserve the order in book.toml. But in any case, it's good to have deterministic execution order, so that mdbook-pdf won't be broken.

I'm wondering, if a renderer requires a certain order if it would make sense to instead have an explicit order like preprocessors do?

It can be good to have an explicit order like preprocessors do in the long run, but it's not necessary for mdbook-pdf then in the short term, as it solely relies on html backend's generated files, and p is after h if it's executed in alphabetical order.

[ehuss]

Thanks!