Support custom "project local" crate group in `group_imports`

📋 Description

For the sake of example, lets say a project is composed of the following crates: coolapp-utils, coolapp-backend, and coolapp-frontend

It would be great if group_imports supported a custom grouping between "external" crates (from crates.io) and "project local" crates:

// somewhere in `coolapp_frontend`

use alloc::alloc::Layout;
use core::f32;
use std::sync::Arc;

use chrono::Utc;
use uuid::Uuid;
use log::Level;

// At the moment, `group_imports = StdExternalCrate` fuses this group with the group above.
use coolapp_utils::frobnicate;
use coolapp_backend::api::ApiVersion;

use super::schema::{Context, Payload};
use super::update::convert_publish_payload;
use crate::models::Event;

Note that different projects have different notions of what constitutes a "project local" crate. Some examples I've come across in the past have included:

• workspace local crates
• crates that share a prefix, but are pulled from crates.io
• crates imported via a local relative path
• etc...

Since there wouldn't be any way to automatically determine which crates fall into which category, one reasonable implementation might be to modify the current "External" crate grouping to support being arbitrarily divided into two (or more?) groups.

While this wouldn't be a *perfect* solution (after all, users could still inadvertently import "project local" crates above "external" crates), it would be a step in the right direction, and offer a much needed bit of flexibility to group_imports.

Start by locating the existing group_imports implementation and its tests, then compare the current StdExternalCrate behavior with the example grouping in this issue. Done means users can configure a distinct project-local crate group while preserving the existing external, standard-library, and local-module behavior.