Debug logging RFC

- knowing what flags are set on layers is useful. See [this bug](https://github.com/paketo-buildpacks/dotnet-core-aspnet/pull/384?notification_referrer_id=NT_kwDOAUVxnrM0Mzg1OTUwMjIxOjIxMzI4Mjg2&notifications_query=is%3Aunread#event-7371265282)
- knowing what env vars are set (and which ones the buildpack is noticing) is useful

- what do Java buildpacks output when debug logging is enabled? (use -q to get less crap from maven)
- Whenever I do a build with the Java buildpacks the logs feel super overwhelming compared to the logs the non java buildpacks output. Although, I wonder if Java/Spring users specifically needs these extra verbose logs
- the java buildapcks log basically every struct/file that's outputted from the build / detect phase, even if it's empty (e.g. "layer env.build <= map[]")

- env var configuration values at build and detect time
- enumerate returned layers and their flags, env vars set on the layers and their values
- SBOMs that will be generated
- build plan contributions from detection phase

- should we log layer metadata? (maybe it's just noise sometimes?)
- would someone investigating a failed build gain any insights into failures from this information?
- should we log the incoming buildpack plan before resolution happens? <-- this will help get more visibility into how things are working; though we already log version sources and order of precedence. maybe that's more informative?
- should we log all metadata about the buildpack? (from its buildpack.toml)
- no
- should we log BINDINGS? should we log Platform Environment?
- should we log the outputted slices and what's in them?
- yes, bindings are user set and often misunderstood

- Ask: See something in debug logs with actual expected? What does that mean?

Writing layer metadata: /layers/paketo-buildpacks_spring-boot/spring-cloud-bindings.toml <= {LayerTypes:{Build:false Cache:false Launch:true} Metadata:map[cpes:[cpe:2.3:a:vmware:s
pring_cloud_bindings:1.10.0:*:*:*:*:*:*:*] id:spring-cloud-bindings licenses:[map[type:Apache-2.0 uri:https://github.com/spring-cloud/spring-cloud-bindings/blob/main/LICENSE]] nam
e:Spring Cloud Bindings purl:pkg:generic/springframework/spring-cloud-bindings@1.10.0 sha256:1f5b781f8bd0d6b85ab2462e4b98d36782a2227fef5b168db174b3959a0ebebe stacks:[io.buildpacks
.stacks.bionic io.paketo.stacks.tiny *] uri:https://repo.spring.io/release/org/springframework/cloud/spring-cloud-bindings/1.10.0/spring-cloud-bindings-1.10.0.jar version:1.10.0]
Name:spring-cloud-bindings Path:/layers/paketo-buildpacks_spring-boot/spring-cloud-bindings BuildEnvironment:map[] LaunchEnvironment:map[] SharedEnvironment:map[] Profile:map[] Ex
ec:{Path:/layers/paketo-buildpacks_spring-boot/spring-cloud-bindings/exec.d}}
Check If Layer Restored -> tomlExists: %!s(bool=false), layerDirExists: %!s(bool=false), dirContents: [], cache: %!s(bool=false), build: %!s(bool=false)
Expected metadata: map[files:8baa37cffd86e899d8f71839990db88d42ec0f46949c550aabdc673555739f70]
Actual metadata: map[]
  Web Application Type: Contributing to layer
    Reactive web application detected

# Standards for Minimum Debug Logging Output

## Summary

{{A concise, one-paragraph description of the change.}}

## Motivation

{{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}}

## Detailed Explanation

{{Describe the expected changes in detail.}}

## Rationale and Alternatives

1. Don't standardize debug logging output. It creates more rules for buildpack authors to follow, and maybe different things make sense in different language ecosystems. One standard to rule them all doesn't make sense.

{{Discuss 2-3 different alternative solutions that were considered. This is required, even if it seems like a stretch. Then explain why this is the best choice out of available ones.}}

## Implementation

{{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}}

{{THIS SECTION IS REQUIRED FOR RATIFICATION -- you can skip it if you don't know the technical details when first submitting the proposal, but it must be there before it's accepted.}}

## Prior Art

{{This section is optional if there are no actual prior examples in other tools.}}

{{Discuss existing examples of this change in other tools, and how they've addressed various concerns discussed above, and what the effect of those decisions has been.}}

## Unresolved Questions and Bikeshedding

{{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}}

{{REMOVE THIS SECTION BEFORE RATIFICATION!}}