Rename fn_args_layout config option

[calebcartwright]

We previously (#3803) refactored the arg name to param internally within rustfmt where appropriate to reflect the upstream changes (rust-lang/rust#62426), but did not change the public/external-facing fn_args_layout config option because that would have been a breaking change.

However, this config option is indeed used as part of the formatting of the parameters in a fn signature, not in the formatting of args in a fn call. As such this should also be renamed as part of the major version release (fn_params_layout seems like a reasonable name)

@topecongiro I've added this to the 2.0 milestone per our previous discussion in #3803 (comment), but of course feel free to change that if you think we should defer it.

Below are the steps involved for anyone interested in working on this:

• Rename the configuration option and update the help text in rustfmt-core/rustfmt-lib/src/config.rs
  

  rustfmt/rustfmt-core/rustfmt-lib/src/config.rs

  Lines 111 to 112 in 7194d52

  	fn_args_layout: Density, Density::Tall, true,
  	"Control the layout of arguments in a function";

  • make sure to update the corresponding test in that file too https://github.com/rust-lang/rustfmt/blob/master/rustfmt-core/rustfmt-lib/src/config.rs#L556

• Rename the corresponding test files/update config references under rustfmt-core/rustfmt-lib/tests/{source,target}

  • For example, rename tests/source/fn_args_layout-vertical.rs (and the same for the matching file under tests/target)to fn_params_layout-vertical.rs and the inline config to be // rustfmt-fn_params_layout: Vertical
  • Same thing for tests/{source,target}/configs/fn_args_layout, rename the directory and update the inline config in the files with the new config option name
    

    rustfmt/rustfmt-core/rustfmt-lib/tests/source/fn_args_layout-vertical.rs

    Lines 1 to 2 in 7194d52

    	// rustfmt-fn_args_layout: Vertical

• Rename/update the corresponding section in Configurations.md

[karyon]

Reopening for 1.x according to @calebcartwright's comment: "there should be a path to a "soft" deprecation where we just print a warning when encountering the option for user awareness, but automatically map the value over to the new option. [...] anyone that wants to work on that could use the commits from #4163 as a building block, and then just add the warning/mapping behavior on top"