Improve S109 messaging to align with the implementation

[andrei-epure-sonarsource]

Currently S109 only tells users to move magic numbers into well named variables or constants.

However, the rule implementation also ignores any construct with magic numbers which has the result stored in a variable or constant, because literalExpression.FirstAncestorOrSelf<VariableDeclarationSyntax>() != null will go up the tree hierarchy until reaching a variable declaration somewhere in the ancestor list.

For example:

var fooResult = Bar(42); // is currently considered compliant
var fooResult = Bar(42, Bar(110, Bar(233, 23454, Bar(999)))); // compliant ?!

I am not sure if this was intended as the test cases are very simplistic and did not include such examples. Removing this check would make the rule even more noisy than it is, although it surely has lots of false negatives as well.

Having this said, if we want to keep the existing behavior of the rule, it would be more useful (and honest) to tell users to use well-named variables when employing magic numbers in some constructs.

For example:

   Foo(new IntPtr(123456)); // Noncompliant {{Assign this object creation with magic number '123456' to a well-named variable/constant, and use that instead.}}
//     ^^^^^^^^^^^^^^^^^^

HOW:

• the rule needs to be re-written using a CSharpSyntaxWalker that would collect information in each class member and avoid raising duplicate issues
• we could decide to stop at one level of the parent hierarchy, like below:

new Bar(100, Foo(200, 300)); // Noncompliant {{Assign this object creation with magic number '100' to a well-named variable/constant, and use that instead.}}
// Noncompliant@-1 {{Assign this invocation using magic numbers '200', '300' to a well-named variable/constant, and use that instead.}}

Like this, we would ensure there cannot be abuse of this feature.