Alternative PathConverter for TeamMailbox cross domain support

[j-hellenberg]

@chibenwa Hi.

Switching to this location to continue our discussion on shared mailboxes now, after you (understandably) told us that bringing the TeamMailboxes (shared namespaces) from this repository into James core is currently not desired.

Getting shared mailboxes for James would still be nice for us, but as the TMail-backend almost fits our needs now
and our development capacity is (sadly) quite limited, we are more interested in adopting the TMail-backend now.

The only thing holding us back is the single-domain restriction for TeamMailboxes. I did a small
spike and figured it should be possible to get rid of that in three fairly straight-forward (e.g., small change-set) steps:

1. In TMail, provide a PathConverter very similar to the current TMailPathConverter except for the rewriting behaviour:

   Currently, the TMailPathConverter rewrites #TeamMailbox.<team>.<folder> into MailboxPath(#TeamMailbox, team-mailbox@<domain-of-current-user>, <team>.<folder>) and vice versa.

   Our alternative converter (see POC here) would rewrite #TeamMailbox.<team>@<domain>.<folder> into MailboxPath(#TeamMailbox, team-mailbox@<domain>, <team>.<folder>) and vice versa.

2. In James-core, IF configured to do so, disable the same-domain validation when storing rights (see Ticket, POC here).

3. (Optional) In James-core, make the default domain separator configurable so that mail clients can show TeamMailboxes as team@domain.tld instead of the escaped team@domain__tld

We would kindly like to ask whether you would be willing to accept our contribution of the alternative PathConverter into the TMail-backend, that could be enabled on-demand using an alternative TMailIMAPModule and a choosePathConverter method in the PostgresTmailServer?
Clients could then choose whether they prefer a display of teams in their mail-client as team (with cross-domain-support disabled), or more explicitly as team@domain (with cross-domain-support possible, but only if activated).

Note that some teams (in our company, at least) appear to prefer the longer version anyway, as it more
clearly communicates that team is actually backed by the team@domain mail address and not only some
kind of shared folder they can sort their mails in.
This might be obvious to techies like us, but while doing IT support tasks, I've learned that preemptively getting rid of
as many sources of confusion as possible is quite often a good idea.

We would be gladly contributing the code and writing the tests for our proposal (and also contribute the necessary changes to the James-core).