[lock-tidy] Put warning behind feature flag (#2171)

## Summary

`--tidy-lockfile` is not reliable, so put this warning behind a feature
flag until it is fixed.

## How was it tested?

Ran `devbox install` with missing outputs in lockfile, did not see
error.

[lock-tidy] Put warning behind feature flag (#2171)

## Summary

`--tidy-lockfile` is not reliable, so put this warning behind a feature
flag until it is fixed.

## How was it tested?

Ran `devbox install` with missing outputs in lockfile, did not see
error.

[Devbox] introduce devopt.EnvOptions (#2159)

## Summary

From the EnvOptions docblock:
```
// EnvOptions configure the Devbox Environment in the `computeEnv` function.
// - These options are commonly set by flags in some Devbox commands
// like `shellenv`, `shell` and `run`.
// - The struct is designed for the "common case" to be zero-initialized as `EnvOptions{}`.
```

This gets rid of the pseudo-global state in the `Devbox` struct where we
were setting `pure`, `preservePathStack` and `omitNixEnv` values.

## How was it tested?

TODO:
- [x] CICD should pass
- [x] Ensure `devbox global` and `devbox` omitNixEnv works as expected
- [x] Ensure `pure` works as expected for `devbox shell --pure`.

[devbox] run: skip re-computing Devbox State if in devbox shell (#2144)

## Summary

This PR implements a change to the semantics of `devbox run`.
BEFORE:
`devbox run` would always ensure that the Devbox State and Environment
is up-to-date.
AFTER:
`devbox run` will only do so when _outside_ a Devbox Environment (i.e.
`devbox shell` or equivalent like direnv-enabled shell).

The motivation is two fold:
1. Speed. Users often want to just run a quick script, this slows them
down.
2. Users often have init-hooks which are more appropriate for one-time
setup, rather than when running a utility script inside a `devbox shell`
that has already been set up appropriately.

This was shared in the Discord channel for feedback:
https://discord.com/channels/903306922852245526/1009933892385517619/1248724103750483978

Notably, the focus there was on skipping the init-hooks, but in this PR,
we are going one-step beyond that to ensure the Devbox State itself is
not re-computed. The reason is that rather than _partially_ updating the
Devbox State and Environment (partially, because init-hooks are part of
setting up the environment) we'd rather eschew the step entirely. This
feels more straightforward for users to reason about.

## How was it tested?

Did a basic sanity test in two scenarios:

1. Running the script in a `devbox shell` or direnv-enabled environment
does NOT recompute the Devbox state.
2. Repeated the sanity test when outside of the Devbox environment, and
confirmed it does recompute the Devbox state.

[CI] Update go-releaser action (#2143)

`--rm-dist` flag is deprecated in newer versions of Goreleaser in favor
of `clean`: https://goreleaser.com/deprecations/#-rm-dist

Release action was failing due to the deprecated flag. This PR replaces
it with the new clean flag

## Summary

## How was it tested?

Signed-off-by: John Lago <[email protected]>

[CI] Update go-releaser action (#2143)

`--rm-dist` flag is deprecated in newer versions of Goreleaser in favor
of `clean`: https://goreleaser.com/deprecations/#-rm-dist

Release action was failing due to the deprecated flag. This PR replaces
it with the new clean flag

## Summary

## How was it tested?

Signed-off-by: John Lago <[email protected]>

nixcache: improve sudo prompt and help docs (#2107)

Refactor the list command (#2101)

## Summary
Refactor the list command into its own file. Also update the description
to be more accurate.

## How was it tested?
1. Verified the `list` command is updated with the new message in the
`--help` command output
2. Verified the `list` command outputs the same list of packages before
and after this change (compared my local `devbox` install output to the
output in my `devbox shell` with these changes).

nix: allow unfree and insecure in cache upload (#2078)

Add the `NIXPKGS_ALLOW_UNFREE` and `NIXPKGS_ALLOW_INSECURE` environment
variables to `nix copy` commands so that those packages can be uploaded
by default. This also requires the `--impure` flag so that Nix respects
the environment variables.

Revert "[perf] Skip cache check if store path exists locally" (#2054)

Reverts #2042

#2042 introduced a bug where adding non-cached packages
would fail to add them to the flake on the first attempt. (it would
succeed on subsequent attempts after the package is already in the
store).

The root cause is that `fetchNarInfoStatus` gets called twice per
package (even though we cache it and we're not supposed to call it
twice). The first call returns `false` because the package is not
cached. The second call returns `true` because the package is already in
store. This discrepancy essentially causes the package not to appear on
the flake at all. When updating state again, the package is already in
the nix store so both `fetchNarInfoStatus` calls return true.

I think reverting this is best immediate course of action. In follow up
we should fix `fetchNarInfoStatus` so it only gets called once (it will
improve performance and is more correct).

Later on we can think of better way to do #2042. The
current implementation is a bit fragile and not 100% consistent with the
initial intention of the function, so I'm concerned it can lead to more
bugs in the future.