[Breaking Change] Disable / eliminate RemovedClientParameter breaking change rule

[mikekistler]

The RemovedClientParameter rule is reporting many false positive issues and is unnecessary.

A common example of false positive RemovedClientParameter issues is when a service replaces a parameter definition with a reference to the same parameter in the common-types file. In this case the parameter is not changed -- simply defined elsewhere, so there is no issue.

I think this check is also unnecessary because if the reference to this parameter was changed to something that was not equivalent this would trigger other error messages.

We should eliminate false positives as they can obscure real problems (e.g. by pushing them out of the top 50 shown in the PR report) and waste reviewer time in investigating them.

I think this rule should be disabled for now and considered for complete removal in the near future if there are no unforeseen consequences from disabling it.

[raych1]

@jianyexi , can you investigate?

[jianyexi]

Agreed, one case is that a 'parameter' is renamed but will not cause the SDK breaking change