[MSHADE-465] Limit depth of transitive dependency promotion

**[Bryan Beaudreault](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=bbeaudreault)** opened **[MSHADE-465](https://issues.apache.org/jira/browse/MSHADE-465?redirect=false)** and commented

In order for a shaded jar to be a drop-in replacement, promoteTransitiveDependencies should be true. This has an annoying side-effect of flattening the dependency tree. For example, suppose you have a project named MyShadeModule with the following dependency tree:

```java
MyShadeModule
-> Module A
-> Module B
-> Module D
-> Module E
-> Module C
```

Let's say you include Module A in the shaded jar. If promoteTransitiveDependencies you'll end up with the following:

```java
MyShadeModule
-> Module B
-> Module D
-> Module E
-> Module C
```

This is a frustrating result, because let's you have Module B under dependencyManagement in a downstream project. Which version you pin Module B to might dictate which transitive dependencies it would normally include. For example maybe Module B 1.0 depends on D and E, while 2.0 depends only on F.  In a normal non-shaded environment, your downstream project would end up depending on modules B, F, and C. But if you depend on a shaded artifact, you end up with modules B, D, E, F, C.

It would be preferable to limit the max depth of transitive promotion, so that you can end up with the more accurate:

```java
MyShadeModule
-> Module B
-> Module C
```

If you import that module into a downstream project, maven will resolve the transitive dependencies for Module B. This way you can take into account any dependencyManagement in the downstream project.

I realize this may not be the desired behavior for everyone, so it might be good to be a new config option.

---
No further details from [MSHADE-465](https://issues.apache.org/jira/browse/MSHADE-465?redirect=false)

No files or tests are named. Start by locating the promoteTransitiveDependencies setting and the dependency-promotion logic, then define how a maximum depth option should behave for the nested dependency tree shown. Done means a configurable limit preserves only the intended promoted levels and tests cover the example.

Written by the indexing model from the issue text.