Ignore legitimately out-of-order visibility sections in VisibilitySectionOrder

[fourls]

The VisibilitySectionOrder check currently requires that visibility sections be exactly in ascending order of visibility. There are times in which this is impractical, particularly when public types or constants are then used in later declarations:

type
  TFoo = class(TObject)
  public type
    TBar = class(TObject)
      // ...
    end;
  protected
    procedure ProtectedBarProc(Bar: TBar);
  public
    procedure PublicBarProc(Bar: TBar);
  end;

This PR excludes visibility sections with only a single type or const from being checked by the ordering rule.

[Cirras]

There was some offline design review on this one that basically boiled down to:

• the "single type section or const section" heuristic is fine, but could have a lot of false negatives
• a more appropriate solution (with its own set of false negatives) would be to exclude any visibility section that we can verify contains a declaration with a usage further down in the type declaration

[fourls]

Reimplemented with new design considerations.

[fourls]

Reimplemented:

As the check loops over the sequential visibility sections, it maintains a stack of previous sections. When the current section has a lower visibility than the section before it, the stack is popped until the top element is not excluded. If the stack is now empty, does not raise an issue. If the current section has a lower visibility than the new "previous section", raises an issue.

[Cirras]

👍