Add `file_name_declarations_location` option for `file_types_order`

New Issue Checklist

• I've Updated SwiftLint to the latest version.
• I've searched for existing GitHub issues.

Feature or Enhancement Proposal

Please add a file_name_declarations_location option for file_types_order that accepts values:

• require_start: All declarations for a type whose names match the file name must be before all other declarations. These declarations must be relatively ordered in the same order as other declarations (e.g., for a file named X+Y.swift), all declarations for X should be before declarations for all other types; Iif struct is before extension, then struct X must be before extension X, before struct *, before extension * (where * is any type other than X).
• consistent_start: Similar to require_start, except that all declarations that match the file name may be before other declarations, or may be in their normal place; i.e. it's all or nothing.
• allow_start: Similar to consistent_start, except that declarations that match the file name on an individual basis may be before other declarations, or may be in their normal place.
• default (default): File name declarations are treated the same as all other declarations.

Please also add:

1. An declarations_generic_over_file_name_location option for file_types_order that applies similar rules to declarations generic over the file name, like [X], X?, Set<X>, etc. It accepts the same values as file_name_declarations_location, plus:
   • file_name_declarations_location: Applies the value from file_name_declarations_location to declarations generic over the file name. Either this or default would be default; most likely the latter.
2. relative_generic_location that accepts values:
   • by_type: e.g., struct X, then extension X, then struct Y, then extension Y, etc.
   • by_declaration_kind: e.g., struct X, then struct Y, then extension X, then extension Y.

Start by locating the existing file_types_order rule and its configuration and test coverage. Compare the requested file-name, generic, and relative ordering modes with the current behavior, then define how each option should be represented and validated. Done means the new options work for the listed declaration-order examples and are covered by tests and configuration documentation.