Feature - Add a repo package dependency matrix/tree for any reference to a project from this repo & developer dependencies package guildlines

It can be extremely challenging to determine which packages are required and which come bundled in this monorepo. For example, the office-addin-lint package includes other packages from this repository, but the README does not explicitly mention these dependencies.

If your add-in was originally created using Yo Office and you’re attempting to upgrade the packages to the next major version, browsing this repository may give the impression that all its packages should (or at least could) be added to your add-in. In reality, only a few key packages should be included, as these key packages bring in the necessary secondary packages from this repository as dependencies. Without examining the repository’s code, a developer could inadvertently add the same secondary package twice to their project—potentially with conflicting major versions.

If there is a naming convention in this repository that indicates whether a package is a key package or a secondary package, it isn’t immediately clear.

Guidelines should also be established regarding whether third-party dependencies should or should not be included as developer dependencies in an add-in project. Example projects in this and other OfficeDev repositories exhibit inconsistencies when it comes to including third-party package that are referenced by OfficeDev packages as to if the third-party package should or should not be incluede as a developer dependency.

No implementation files or tests are named. Start by inventorying the repository packages and the README and example projects referenced in the issue, then define how package relationships and third-party developer-dependency guidance should be presented; done means the dependency matrix or tree and consistent guidelines are established.