allow *%W for better readability (Lint/UnneededSplatExpansion)

[md-work]

In certain scenarios, using *%W may improve readability. So there should be exceptions to: Lint/UnneededSplatExpansion

Most of those scenarios are when building shell commands.

E.g.:

# filename may be an arbitrary string, containing spaces and other weird stuff.
filename = "file \" ' name.txt"

# Unsafe!
# May lead to wrong behavior. E.g. delete `file` and `name.txt`, but not `file name.txt`.
system('sudo -u ' + target_user + '/usr/bin/rm -r -- ' + filename)
system("sudo -u '#{target_user}' -- /usr/bin/rm -r -- '#{filename}'")

# Safe, but hard to read.
# And this rm example is still a simple shell command.
# Longer shell commands get much harder to read in this style.
system('sudo', '-u', target_user, '/usr/bin/rm', '-r', '--', filename)

# Safe and good to read. But triggers Lint/UnneededSplatExpansion
# *%W[ isn't very pretty to read. But the important shell command is clearly recognizable
system(*%W[sudo -u #{target_user} -- /usr/bin/rm -r -- #{filename}])

Be aware, that system is not the only method covered by this. Open3.... is also affected and I'm actually using a custom method with adds additional checks when running external command. So excluding Lint/UnneededSplatExpansion for certain methods may not be a satisfying solution.

This might sound similar to #3512 and #6146.
But here the problem is, that using *%W explicitly improves readability.

[rrosenblum]

I can see the benefit of improved readability. I feel like this is a highly specific use case. I'm not sure that there is a great solution for this. A few ideas that I have are:

1. Create a white list of methods that you are allowed to pass splat expansion to
   We could have a default list of methods and allow users to add to the list. I'm not sure how many methods this would need to apply to
2. Create a configuration that completely ignores *%W
   This would weaken the overall usefulness of this cop. If we go this route, would it be worth while to make all percent variables configurable?
3. Do nothing and rely on rubocop:disable comments
   This is already supported. It can be annoying to need to flag all of these calls. It also means that other people that contribute to your code should know why the cop is disabled so that they don't change the code.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

[md-work]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

The problem is still present in 0.74.0.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

[md-work]

I guess this is still a problem.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

[stale]

This issues been automatically closed due to lack of activity. Feel free to re-open it if you ever come back to it.