Allow disabling bad-option-value and unrecognized-option with --disable=all

[jacobtylerwalls]

We should allow --disable=all to disable the messages emitted for a pylintrc, e.g. bad-option-value and unrecognized-option, as it's slightly unexpected to not be able to disable everything.

The pylintrc used in the following run is found here.

% pylint music21 --disable=all 
************* Module /Users/.../music21/.pylintrc
.pylintrc:1:0: E0012: Bad option value for --disable. Don't recognize message bad-whitespace. (bad-option-value)
.pylintrc:1:0: E0012: Bad option value for --disable. Don't recognize message bad-continuation. (bad-option-value)
.pylintrc:1:0: E0012: Bad option value for --disable. Don't recognize message no-self-use. (bad-option-value)
.pylintrc:1:0: E0012: Bad option value for --disable. Don't recognize message star-args. (bad-option-value)
************* Module /Users/.../music21/.pylintrc
.pylintrc:1:0: E0015: Unrecognized option found: profile, files-output, bad-functions, function-name-hint, variable-name-hint, const-name-hint, attr-name-hint, argument-name-hint, class-attribute-name-hint, inlinevar-name-hint, class-name-hint, module-name-hint, method-name-hint, no-space-check (unrecognized-option)

Originally posted by @jacobtylerwalls in #6556 (review)

[DanielNoord]

This will be quite tricky as this is dependent on the order in which things are parsed (and therefore likely impossible).
We parse configuration files before command line as we consider command line "higher" in the hierarchy of configuration options.

Similar to my comment in #6556, we could try and create a system to defer bad-option-value to the end of a run and then see if it should be emitted, but that feels like a lot of extra complexity for very small gains. Disabling bad-option-value (again before the to-be-disabled options) in the rcfile should work though. This is a similar case of: if you want to avoid a message disable it before it will be emitted instead of after it as been emitted.

I do think that we might want to update our documentation about this because I can understand that somebody will wonder about this one day.

Edit: @jacobtylerwalls I might even consider this a won't fix? But please let me know what you think about it!

[jacobtylerwalls]

Yeah this might turn out to be a won't fix and doc it, but I'll just leave it open long enough for someone (possibly me?) to spend a very short cycle making sure we're not missing anything obvious.