Populate Bundle.entry.response.outcome with validation warnings

[lmsurpre]

Is your feature request related to a problem? Please describe.
While reviewing our bundle processing code, I noticed that we pass validation warnings back through Bundle.entry.resource (at least in some cases).

This is the proper location for errors, but for warnings the spec defines a supplemental location: Bundle.entry.response.outcome

From the spec:

For a POST/PUT operation, this is the equivalent outcome that would be returned for prefer = operationoutcome - except that the resource is always returned whether or not the outcome is returned.
This outcome is not used for error responses in batch/transaction, only for hints and warnings. In a batch operation, the error will be in Bundle.entry.response, and for transaction, there will be a single OperationOutcome instead of a bundle in the case of an error.

Describe the solution you'd like
Lets start adding our validation outcomes to Bundle.entry.response.outcome.

However, I still like having clients be able to control whether the resource content comes back in the Bundle.entry.resource or not, so I propose we do this:

• always populate Bundle.entry.response.outcome with validation hints / warnings
• when return=minimal (default), omit the resource contents from Bundle.entry.resource
• when return=OperationOutcome, write an interaction-related (not validation-related) OperationOutcome in the Bundle.entry.resource
• when return=representation, write the resulting resource contents to the response Bundle.entry.resource

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Acceptance Criteria

Additional context
There is plenty of room for cleanup here as well.

1. We loop through the entire bundle for each method, whereas we really only need to iterate this list once or twice.
2. We create a responseBundle up front and then we insert the entries one-at-a-time while we process them. But that was designed when our model was mutable...each "insert" is actually copying the bundle into a new builder and then building a brand new bundle. All of this copying is unnecessary and could slow things down / bloat the memory usage for large bundle requests.

[d0roppe]

Verified that this is now working as described for the different options listed.