…not require CDK CLI to be installed (#644)

The new engine will eventually unlock performance optimizations and in
generally be more consistent with CLI behavior. Use like this:

```console
integ-runner --unstable toolkit-lib-engine
```

For now, this change focuses on feature parity as there are some
optimizations that will be tricky to do without refactoring the codebase
and/or having a bunch of conditionals in the code base.

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license

Right now the CLI logs the entire environment to debug logging. This is
a lot of data, and potentially also includes tokens we'd rather don't
end up in logging.

Instead, just log our additions to the existing environment.

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license

The test that checks that notices are fetched through the proxy
sometimes fails; it is correctly cleaning the `notices.json` file from a
temporary directory before running the command that should fetch
notices, but the temporary directory is wrong.

When running the command it is setting `CDK_HOME` to a directory, and
`CDK_HOME` will be used to determine the location of the notices cache;
but when removing the file it is removing it from the user's home
directory, as if `CDK_HOME` was never set.

What's not clear to me is why this wouldn't *always* fail... but I'm
pretty sure the new behavior is correct.


---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license

In cdklabs/node-backpack#1167, we moved the code
of this private tool to the external `node-backpack` package.

Remove it here and use the external tool wherever we used to use the
private package.

Closes #17

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license

The init tests used always to use the library version that was baked
into the CLI. The CLI has since grown a `--lib-version` flag that allow
specifying the library version.

Respect the library-under-test version that is being given to the integ
tests, and use that version to test with.

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license

#603)

Because `cdk-assets` CLI depends on floating versions of dependencies,
it may break when new 3rd party dependencies are released, or when it is
installed just around the time a new version of AWS SDKv3 gets released
(because that has hundreds of packages that all refer to each other by
specific version, but they're subject to publishing/replication latency
so they don't all become instantaneously available).

We used to generate a shrinkwrap file for the `cdk-assets` CLI but
apparently that didn't work because we're still getting reports of
breakage.

Instead, we'll resort to bundling the dependencies of `cdk-assets` into
the CLI itself, so it cannot go wrong.

Because the `cdk-assets` package does double duty as a CLI package as
well as a library package, we can't just naively stick the `BundleCli`
job onto the package: doing that would remove all the bundled
dependencies from the `package.json` list, which breaks its function as
a library.

Instead, we're splitting the `cdk-assets` package in two:

* `cdk-assets`: will continue to contains the CLI, which will be bundled
* `@aws-cdk/cdk-assets-lib`: the core portion of the assets publishing,
available as a library.

Because `cdk-assets` can no longer be used as a library, we have bumped
the major version to `4` to indicate this change in API surface. In CDK
pipelines we install `cdk-assets@latest`, so it will automatically pick
up major version 4 once released.

(While this PR is strictly speaking a breaking change, I'm not adding
any "breaking change" markers into the PR description, because this is
changing many files across multiple packages, and I don't trust the
automatic major version bumping script to not accidentally MV bump
something I didn't intend to)

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license

---------

Signed-off-by: github-actions <github-actions@github.com>
Co-authored-by: github-actions <github-actions@github.com>

We're observing a lot of these errors in our integration tests:

```
[09:29:38] Could not refresh notices: _ToolkitError: Network error: Request timed out
```

It could be that our timeout is too short on a heavily congested
machine. Increase the timeout specifically for those cases to improve
the reliability of our tests.

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license