fix(Java, .NET): Let the MPL define dependencies

[texastony]

Issue #, if available:

Description of changes:
Normally, if a package directly uses classes/objects/references/symbols from an other package,
it should declare a direct dependency on that package,
rather than relying on it being in the symbol resolution via a transitive dependency.

However,
the DB-ESDK and the MPL are strongly linked.
Additionally,
they are owned/maintained by the same team,
AWS Crypto Tools.

AWS Crypto Tools can reduce the amount of effort needed
to update the KMS, DDB, Bouncy Castle, and other dependencies
common to both the MPL and the DB-ESDK by breaking the convention
described above.

This helps our customers by reducing Crypto Tools maintenance efforts,
freeing us to innovate or investigate issues.

Closes #1470

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[texastony]

Alas, Dependency resolution in Java and .NET does not work as I thought it.
The MPL's Dependencies are runtime dependencies.
But the DB-ESDK needs them to compile.

If Crypto Tools wants to do something,
we will have to determine a more elaborate solution,
likely using native features of Java, .NET, and any future runtime
to duplicate the information.