Ensure API consistency for builders and builder-like types

[Malax]

Some types don't provide builder-like functionality but have dedicated *Builder types, others have it with the normal type, some have nothing. We should ensure API consistency.

[edmorley]

Since this issue was opened:

• LayerResultBuilder / LayerResult were introduced (in Refactor LayerLifecycle #144)
• DetectResultBuilder and BuildResultBuilder were changed to match LayerResultBuilder's wrapping in a Result (in Change DetectResultBuilder and BuildResultBuilder API to match LayerResultBuilder #209)
• The builder-style methods were removed from LayerContentMetadata (in Remove builder-style methods from LayerContentMetadata #235)

As of now, we have the following builder types:

• DetectResultBuilder
• PassDetectResultBuilder
• FailDetectResultBuilder
• BuildPlanBuilder
• BuildResultBuilder
• LayerResultBuilder

(We'll also have ProcessBuilder once #265 merges)

We then have the following chainable methods on non-builder types:

• Launch::process()
• Env::insert()
• LayerEnv::chainable_insert() (which is a chainable version of LayerEnv::insert)
• LayerEnvDelta::insert()

There are a few issues with the chainable methods on non-builder types:

1. They are inconsistent with the builder style patterns we're using elsewhere (though we may decide this is fine in some cases?).
2. In the case of Launch, there is only a method for inserting into processes, not any of the other fields on the struct.
3. For Layer / LayerEnv there is a mixture of having the standard insert() being chainable vs having a separate chainable_insert().

How do we want to resolve these?

[Malax]

At this point, I'm leaning towards explicit Builder suffixes and non-consuming builder implementations. Explicit names aid with discoverability and non-consuming builders are the "gold standard" in the Rust ecosystem. They allow our users to do chained calls and mutable values with the same API.