idempotence_tests are unstable when setting inline rustfmt comments

[IVIURRAY]

As I was generating the code for #6000 I noticed that when setting config options with rustfmt comments the test would become unstable. Sometimes the test would pass and sometimes the same test would fail without changing any code. We believe this is down to the order that the config items get applied. Setting one config param before the other can cause a conflict and incorrect setup for the test.

To resolve this, we moved the test's config into a .toml file (as can be seen in the MR) which applies them in the correct order.

More deatils can be found in #6000 and the comment here. I've pasted some of it below for quick reference.

My hunch is that the issue is related to setting the configs inline with the rustfmt comments like //rustfmt-{key}: {value} in read_config. From what I can tell read_significant_comments returns a HashMap<String, String>, and when we try to iterate over it we don't necessarily iterate over the configurations in the same order that they're listed in the file. Sometimes we set the max_width=120 before we set attr_fn_like_width=120, and in that case everything works out. In other cases we try to set attr_fn_like_width=120 first, and that fails since we don't allow any width configuration to exceed the max_width, which is still set to its default of 100. so attr_fn_like_width would also get set to 100.

How to reproduce?

Run the following test script. Run it multiple times...sometimes it passes and someetimes it fails.

rustfmt/tests/target/issue-5801/attribute_does_not_wrap_within_max_width.rs

Lines 1 to 10 in fb36c14

	// rustfmt-max_width: 120
	// rustfmt-version: Two
	// rustfmt-attr_fn_like_width: 120
	pub enum Severity {
	#[something(AAAAAAAAAAAAA, BBBBBBBBBBBBBB, CCCCCCCCCCCCCCCC, DDDDDDDDDDDDD, EEEEEEEEEEEE, FFFFFFFFFFF, GGGGGGGGGGG)]
	AttrsWillWrap,
	#[something_else(hhhhhhhhhhhhhhhh, iiiiiiiiiiiiiiii, jjjjjjjjjjjjjjj, kkkkkkkkkkkkk, llllllllllll, mmmmmmmmmmmmmm)]
	AttsWontWrap,
	}