fix(weaver-corda): added duplicate handling strategy in build.gradle

[sandeepnRES]

This bug was detected in release of v2.0.0-rc.4, by the deployment workflow

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[petermetz]

@sandeepnRES Please include the same information in the commit message next time that you added in the PR description after the fact.

Context: The commit parity check is getting stabilized (it was failing with false negatives up until recently) and it failing on this PR seems like a legit problem because the body of the commit message is empty while the PR description has This bug was detected in release of v2.0.0-rc.4, by the deployment workflow in it. So the This bug was detected in release of v2.0.0-rc.4, by the deployment workflow string is only present in a private database (GitHub) and not accessible through the commit log.

We haven't turned on the PR commit parity check yet to be mandatory but eventually (hopefully in the near future) it would be great if we could do that and so I'm just setting the stage for that with this comment (and a few more where I'll let people know as well).

---

@jagpreetsinghsasan Please try to spread the word about the same in other PRs you review and then in some time from now we can propose to the maintainers to enable the check as a required one. I'm hoping that us talking about it first and calling it out, the transition will be smoother compared to if we just turned it on as mandatory and then everyone would be scrambling with their PRs.

[jagpreetsinghsasan]

Sure @petermetz
Will inform this in reviews and once we see decent amount of PRs with passing checks, we can make this a mandatory one. (Liked how you gave the reasoning to tell the gist of why it was failing as this is a fairly new workflow)