Fixes #4171

- What I did
When the user passes a custom buildkitd.toml config to the builder, and a builder already exists, it is supposed to check it against the existing one. If it matches, reuse it; if not, start a new one.

The problem was that it was always starting a new one, even if it matches. This fixes it and adds tests:

• Fix a bug where it was reusing a bytes.Buffer, so it always would fail to match, as the buffer already had data in it
• Fix a bug to ensure that any pre-processing of the buildkitd.toml happens before comparison
• Add tests

For the pre-processing, the problem was the following. It would

1. See that there is a custom config
2. Retrieve the config from the existing container
3. Compare the configs
4. If they do not match, pre-process the locally-provided config to provide standard formatting via toml unmarshal/marshal, but more importantly to do any path translations, so that mounted certificates and such use the paths inside the container, rather than outside. This means that the final config toml by definition is different than the one we started with
5. Load the processed config toml into the container

The new process does the following:

1. See that there is a custom config
2. Retrieve the config from the existing container
3. pre-process the locally-provided config
4. Compare the processed config and the one in the container
5. If they do not match, start a new container and load the processed config toml into the container

This way, they match successfully

The test runs 3 builds:

1. With a custom config toml
2. Rerun with the same custom config toml
3. Rerun with a different custom config toml

After each build, it retrieves and saves the container ID for the builder container.

The first two should match, the last should be different.

- How I did it
Fixes in linuxkit binary, and a new test

- How to verify it
CI, which is why I added tests

- Description for the changelog

Fixed bugs and added tests for custom builder config toml