feat: allows users to enter { newlinesBetween } in groups

[hugop95]

Resolves #401
Continuation of #428.

• ✅ PR 1: Add customGroup.newlinesInside option. We will take the opportunity to create a getNewlinesBetweenOption method that will help us later to precisely customize newline behavior between two specific groups.
• ⚙️ PR 2 (this): Add a way to choose a specific newline behavior between two groups. See the proposals here.
  • Proposal 2 is implemented here.

Description

Allows users to enter { newlinesBetween: 'always' | 'never' | 'ignore' } between elements of the groups option. This enables precisely setting/overriding the newline behavior between two groups.

Example:

{
  newlinesBetween: "always", // Default behavior
  groups: [
    "public-property",
    { newlinesBetween: "never" }, // Will override the default behavior
    "protected-property",
    { newlinesBetween: "never" },
    "private-property",
    // Will enforce a newline here because of the default behavior
    "method",
  ]
}

• { newlinesBetween: 'ignore' } is only useful if a newlinesBetween option different from ignore is set.
• Entering two consecutive { newlinesBetween } objects in a group configuration will raise an error: Consecutive 'newlinesBetween' objects are not allowed.

Impacted rules

• sort-imports
• sort-intersection-types
• sort-union-types
• sort-classes
• sort-modules
• sort-object-types

Additional notes

❓ Is this better than proposal 1 ?

Proposal 1:

Adds customGroups.newlinesAbove and customGroups.newlinesUnder options

You can see a proof of concept PR here.

I believe the current implementation is superior:

• Implementing proposal 1 means handling cases where the below group has a newlinesAbove incompatible with the newlinesUnder of the above group.
• It's not as easy to read the newline configuration. This implementation allows users to quickly see where newlines are enforced (or not) by looking at groups.
• Proposal 1 can co-exist with proposal 2, so it's always theoretically possible to have both implementations later if really needed.

❓ Why not use string tokens instead of an object, such as "newlinesBetween:always" ?

I believe that an object gives us more flexibility in the future if we want to allow users to pass additional options.
It's also easy to distinguish those objects from the group names.

What is the purpose of this pull request?

• New Feature