Optimization of Arch Rules for Connector Constraints and Violation File Updates

Description:
Potential optimization within our Arch rules that could improve the development workflow. This originated from the discussion for PR https://github.com/apache/flink/pull/24492

1. Connector Constraints:
The current Arch rule, `CONNECTOR_CLASSES_ONLY_DEPEND_ON_PUBLIC_API`, was implemented to prevent internal code changes in Flink from affecting the compilation of connectors in external repositories. This rule is crucial for connectors that are external, but it may be unnecessarily restrictive for the filesystem connector, which remains within the same code repository as Flink. Maybe we should consider excluding the filesystem connector from this rule to better reflect its status as an internal component.

2. Preconditions Class Promotion:
The majority of Arch rule violations for connectors are related to the use of `Preconditions#checkX`. This consistent pattern of violations prompts the question of whether we should reclassify `Preconditions` from its current internal status to a `Public` or `PublicEvolving` interface, allowing broader and more official usage within our codebase.

3. Violation File Updates:
Updating the violation file following the `freeze.refreeze=true` process outlined in the readme proves to be difficult. The diffs generated include the line numbers, which complicates the review process, especially when substantial changes are submitted. Reviewers face a considerable challenge in distinguishing between meaningful changes and mere line number alterations. To alleviate this issue, I suggest that we modify the process so that line numbers are not included in the violation file diffs, streamlining reviews and commits.