File handle in SpringBootJoranConfigurator should be closed

[dlwldn30]

Sorry for the unrequested rebase on #51385 — you had said you had the branch
locally and I should have left it alone.

Re-submitted from a user-account fork, so "Allow edits from maintainers" applies
here and the tweaks you had locally should push cleanly this time. The change
itself is identical, but the commit is the 4.0.x rebase (915e4775) rather
than the main one you have locally (16f5fffd), since you had retargeted the
base.

SpringBootJoranConfigurator.RequireNewOrMatchingContentFileHandler compares the
resource it is about to write against what is already on disk:

byte[] existingContent = content.getInputStream().readAllBytes();

InputStream.readAllBytes() does not close the stream, and the stream is never
assigned to anything, so nothing can close it afterwards. During AOT processing
the handler is a FileSystemGeneratedFiles.FileSystemFileHandler whose content
supplier returns a FileSystemResource, so this is a real file handle. It is
reached whenever more than one application context contributes the same
resource. FileSystemGeneratedFiles already uses try-with-resources on the
other side of the same interface.

The fix reads the existing content inside a try-with-resources block, three
lines. The test supplies its own GeneratedFiles and a FileHandler whose
content records when its stream is closed, then drives the AOT contribution
through applyTo.

Verified on 4.0.x: aotContributionClosesExistingFileContent fails without the
production change and passes with it, :core:spring-boot:test 3767 tests with
0 failures and 14 skipped, and checkFormatMain, checkFormatTest,
checkstyleMain and checkstyleTest pass.

Contributed on behalf of Goatshave.

[dlwldn30]

@snicoll both are re-submitted from my user account now — #51398 (this one, 4.0.x) and #51399 — and "Allow edits from maintainers" is in effect on both, so the tweaks you had locally should push cleanly.