`organizeDeclarations` custom naming & ordering

[oiuhr]

This PR adds an ability to parametrize order inside organizeDeclarations categories & their respective marks.

I'm not sure about the design so it's up to discussion, but long story short:

We have 6 visibility categories (plus 2 for airbnb conventions, but i guess this number can increase without any major changes) and ~15 type groups. By providing parameters --visibilityorder we sort visibility categories (the same goes for the typeorder), and by --mode parameter we tell which category will be respected as primary sorting group. Each group either take a default mark comment value or custom parametrized with parameters --visibilitymark & --typemark, if provided.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 99.43503% with 1 line in your changes missing coverage. Please review.

Project coverage is 95.19%. Comparing base (4433c16) to head (eb89782).

Files	Patch %	Lines
Sources/FormattingHelpers.swift	99.10%	1 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## develop #1736 +/- ## =========================================== - Coverage 95.24% 95.19% -0.05% =========================================== Files 20 20 Lines 23284 23435 +151 =========================================== + Hits 22176 22309 +133 - Misses 1108 1126 +18 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[oiuhr]

Current questions:

• Is it okay if we cant filter out custom marks? For example: we were using default mark for instance lifecycle group, which was given an // MARK: Lifecycle mark. Then we change up to custom mark, smth like // MARK: Init and // MARK: Lifecycle is replaced. But if we jump from custom to default formatter simply have nothing to compare and just place // MARK: Lifecycle under previously used custom mark. Should we add something like --potentialCategoryMarks to filter them out if needed?
• I couldn't find the way to somehow validate provided parameters. For example --visibilityorder clearly should have 6+ entries in it, all of which should be unique and valid 💀

[calda]

Is it okay if we cant filter out custom marks? For example: we were using default mark for instance lifecycle group, which was given an // MARK: Lifecycle mark. Then we change up to custom mark, smth like // MARK: Init and // MARK: Lifecycle is replaced. But if we jump from custom to default formatter simply have nothing to compare and just place // MARK: Lifecycle under previously used custom mark. Should we add something like --potentialCategoryMarks to filter them out if needed?

To me it seems fine to leave this as-is.