Change platform selection logic

[willmurphyscode]

This PR a couple things going on:

• Fix Platform selection in docker client has unnecessary error #188, essentially by reverting Set the default platform for select sources based on host arch #152.
• Partially re-implement Set the default platform for select sources based on host arch #152 in order to avoid re-introducing Stereoscope pulls different images when using docker: vs registry: from multi-platform images  #149
• Add integration tests to protect against regression of Platform selection in docker client has unnecessary error #188 or Stereoscope pulls different images when using docker: vs registry: from multi-platform images  #149
• Add some tests that use busybox:1.31 on the linux/s390x platform. Previously, tests only used linux/amd64 (which is an architecture match for many modern laptops) and linux/arm64 (which is an architecture match for M1 macs). Adding linux/s390x images lets us pin down the behavior of image pulling that is almost certainly cross-platform. In other words, if we only have arm64 and amd64 test cases, then those test cases flip-flop between cross-platform and same-platform depending on whether the contributor is on an M1 or not, but adding some tests that use a platform found in fewer development laptops gives some tests that are always cross-platform.

I wanted to point out a couple things for discussion:

1. It's not 100% clear to me that Stereoscope pulls different images when using docker: vs registry: from multi-platform images  #149 represented incorrect behavior. I could see an argument that making the registry provider imitate docker's platform selection was the wrong call.
2. This pull request could be 2 different ones, one to fix Platform selection in docker client has unnecessary error #188, and one to re-fix Stereoscope pulls different images when using docker: vs registry: from multi-platform images  #149.
3. The function defaultPlatformIfNil intentionally swallows an error if it occurs. That's because we're trying to guess a default behavior here, and I don't think an attempt to infer the desired default should ever return an error.

[github-actions]

Benchmark Test Results

Benchmark results from the latest changes vs base branch

latest: Pulling from library/ubuntu
tar: Option --mtime: Treating date 'UTC 2019-09-16' as 2019-09-16 00:00:00
goos: linux
goarch: amd64
pkg: github.com/anchore/stereoscope/pkg/file
cpu: Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
docker: 
           │ ./.tmp/benchmark-f29f84a.txt │
           │            sec/op            │
TarIndex-2                   49.43µ ± ∞ ¹
¹ need >= 6 samples for confidence interval at level 0.95

           │ ./.tmp/benchmark-f29f84a.txt │
           │             B/op             │
TarIndex-2                  5.561Ki ± ∞ ¹
¹ need >= 6 samples for confidence interval at level 0.95

           │ ./.tmp/benchmark-f29f84a.txt │
           │          allocs/op           │
TarIndex-2                    93.00 ± ∞ ¹
¹ need >= 6 samples for confidence interval at level 0.95

pkg: github.com/anchore/stereoscope/test/integration
                                      │ ./.tmp/benchmark-f29f84a.txt │
                                      │            sec/op            │
SimpleImage_GetImage/docker-archive-2                   1.968m ± ∞ ¹
SimpleImage_GetImage/oci-archive-2                      1.935m ± ∞ ¹
SimpleImage_GetImage/oci-dir-2                          1.400m ± ∞ ¹
geomean                                                 1.747m
¹ need >= 6 samples for confidence interval at level 0.95

                                      │ ./.tmp/benchmark-f29f84a.txt │
                                      │             B/op             │
SimpleImage_GetImage/docker-archive-2                  356.9Ki ± ∞ ¹
SimpleImage_GetImage/oci-archive-2                     646.3Ki ± ∞ ¹
SimpleImage_GetImage/oci-dir-2                         413.6Ki ± ∞ ¹
geomean                                                456.9Ki
¹ need >= 6 samples for confidence interval at level 0.95

                                      │ ./.tmp/benchmark-f29f84a.txt │
                                      │          allocs/op           │
SimpleImage_GetImage/docker-archive-2                   2.649k ± ∞ ¹
SimpleImage_GetImage/oci-archive-2                      1.567k ± ∞ ¹
SimpleImage_GetImage/oci-dir-2                          1.351k ± ∞ ¹
geomean                                                 1.777k
¹ need >= 6 samples for confidence interval at level 0.95

docker: Error response from daemon: Get "http://localhost/v2/": dial tcp [::1]:80: connect: connection refused.
                                                   │ ./.tmp/benchmark-f29f84a.txt │
                                                   │            sec/op            │
SimpleImage_FetchSquashedContents/docker-archive-2                   22.55µ ± ∞ ¹
¹ need >= 6 samples for confidence interval at level 0.95

                                                   │ ./.tmp/benchmark-f29f84a.txt │
                                                   │             B/op             │
SimpleImage_FetchSquashedContents/docker-archive-2                  2.648Ki ± ∞ ¹
¹ need >= 6 samples for confidence interval at level 0.95

                                                   │ ./.tmp/benchmark-f29f84a.txt │
                                                   │          allocs/op           │
SimpleImage_FetchSquashedContents/docker-archive-2                    21.00 ± ∞ ¹
¹ need >= 6 samples for confidence interval at level 0.95

[spiffcs]

Initial nit comments added - I fully agree with the changes/reverts done to selectImageProvider - I think this clears up the messaging and intent for users and puts it in a better spot than it is currently.

For discussion points:

1. I agree and think in hindsight making registery imitate the docker platform selection is the wrong call. Maybe we can settle on some good language to add to some part of the documentation expressing why they're different and the intention behind the two prefix

2. I think this is fine as a single PR because there is some overlap between the two and it's not and overly complex revert/change =)

3. Oh no! I should have read this before I added my nit comment - This resonates with me and I'm good with the logic of if we're deciding a default then we commit and make a choice and never error. I'm fine with it being it's own function vs a method on the config just wanted to point out the other option since it's a mutation that doesn't return anything =)