Restrict "prefer_initializing_formals" to avoid false positives.

When an explicit initializer or assignment is turned into an initializing formal, it's possible for that to change the semantics if there are other references to the same parameter.

For example:

```dart
// Before:
class C {
  int? x;
  C(int? x) {
    print(this.x);
    this.x = x;
  }
}

// After:
class C {
  int? x;
  C(this.x) {
    print(this.x);
  }
}
```

This prints "null" before and the argument value after.

The fix might even lead to invalid code:

```dart
// Before:
class C {
  int? x;
  int? y;

  C(int? x) : y = (x = 2) {
    this.x = x;
  }
}

// After:
class C {
  int? x;
  int? y;

  C(this.x) : y = (x = 2);
}
```

This becomes a compile error because `x` is final when it refers to an initializing formal in the initializer list.

It's also not enough to look for secondary writes inside the constructor:

```dart
// Before:
class C {
  int? x;
  Function()? closure;
  C(int? x) {
    closure = () {
      print(x);
    };
    this.x = x;
  }
}

// After:
class C {
  int? x;
  Function()? closure;
  C(this.x) {
    closure = () {
      print(x);
    };
  }
}

// Given:
main() {
  var c = C(1);
  c.x = 2;
  c.closure!();
}
```

This prints "1" before and "2" after.

I think the safest thing is to be conservative and not show the lint if there are any other references to the parameter anywhere in the constructor, even reads.

Fix #58607.

Change-Id: Ib976cd5bfc4bf44439ecd4175090dbabfe1cde16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482985
Commit-Queue: Paul Berry <paulberry@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>