AbstractJobConfig - Log and Attempt to resolve duplicate requires

[mbaker3]

Implement a less disruptive outcome if multiple requires of the same type are set on a job config.

This improves the developer experience by allowing developers to continue their test and fix the configuration error later.

What is the current behaviour?

The job config will throw an exception any time a duplicate require is identified.

What is the new behaviour?

In situations where duplicate requires occur the config now logs an error describing the issue but then attempts to accommodate the request and continue execution.

• If the new require is the same as the existing require the new wrapper is disposed. We only need one.
• If the requires are of different AccessTypes but one AccessType is a superset of the other AccessType then the wrapper for the superset access is kept and the other is destroyed. (Ex: Require SharedRead and SharedWrite. SharedWrite is kept and SharedRead disposed.)

What issues does this resolve?

• None?
  • @jkeon not sure if there is an existing issue created for improve this.

What PRs does this depend on?

• None

Does this introduce a breaking change?

• [ ] Yes
• [x] No

[mbaker3]

Snuck in a commit that removes the logged error when ANY duplicate require resolution happens. That logged error doesn't make sense in the usage context anymore. Particularly now that we're adopting the JobPart pattern.