Clarify rationale for package extension naming

[sloede]

Especially in light of issues such as JuliaLang/julia#50873, where users are faced with warnings such as

Precompiling project...
  194 dependencies successfully precompiled in 92 seconds. 10 already precompiled.
  3 dependencies had warnings during precompilation:
┌ SummationByPartsOperatorsDiffEqCallbacksExt [82d7d246-636b-5c42-a4f7-7a8a453087a7]
│  [pid 720185] waiting for IO to finish:
│   TYPE[FD/PID]       @UV_HANDLE_T->DATA
│   timer              @0x107c040->0x7f8e2e0e9060
└
┌ LinearMapsStatisticsExt [364b1850-867c-5a65-9f2f-642d093ba2f6]
│  [pid 704422] waiting for IO to finish:
│   TYPE[FD/PID]       @UV_HANDLE_T->DATA
│   timer              @0x261b550->0x7f6d92ae8f10
└
┌ ExponentialUtilities [d4d017d3-3776-5f7e-afef-a10c40355c18]
│  [pid 712737] waiting for IO to finish:
│   TYPE[FD/PID]       @UV_HANDLE_T->DATA
│   timer              @0x955b000->0x7f9e61c56230
└

it would be very helpful to have both the main package name and the extension trigger package encoded in the extension name (in this example here, it is already done so for SummationByPartsOperatorsDiffEqCallbacksExt and LinearMapsStatisticsExt). This PR adds a sentence to the docs to clarify the rationale for the recommendation to further nudge pkg devs to stick to this convention.

[IanButterworth]

I think the length of that extension name is actually a reason not to include the parent in the name and perhaps we should make Pkg show the parent and the ext name in the output log, like it does during the precompilation process

[sloede]

I agree, it would be even better if the extension name would not show up anywhere without its parent. But is that even feasible?

[IanButterworth]

See #3603

[sloede]

With #3603 incoming, are there any other prominent places left, where an extension's name is shown without its parent? Because if not, I would consider this PR here superseded by #3603 and withdraw it.

[aplavin]

The extension naming scheme suggested in the docs, and followed by many packages, leads to unnecessarily verbose output basically everywhere - starting from regular precompilation progress.
Maybe, it's better to ensure that extension packages are always shown with their parents (solved by #3603?), and actually exemplify and recommend naming ContourExt instead of PlottingContourExt in the docs?
Main motivation for duplicating parent name in the extension was a packagecompiler bug, but it has been solved for quite some time already.

[sloede]

Maybe, it's better to ensure that extension packages are always shown with their parents (solved by #3603?), and actually exemplify and recommend naming ContourExt instead of PlottingContourExt in the docs?

I completely agree. However, as we just saw with this PR, there was yet another case where a pkg extension was shown without reference to its parent. Once somebody with enough knowledge about Pkg.jl is reasonably sure that all such "orphaned" references to pkg extensions have been fixed, this would be a good step though!

[IanButterworth]

It does seem better for extension names to not include the parent, otherwise they get huge, and it feels like too much burden for the developer to get right.

Can we make a list of all the places we need to fix where just the extension name is shown.

I think stack traces are ok because they show the path.

(perhaps this should be an issue)