CLI fails to deploy valid stacks due to cross-platform network mixup

Description

In some cases trying to deploy a valid stack file to a Linux swarm fails, but only when it is being deployed from Windows. The Docker CLI code in question appears to have confused the set of built-in (i.e. not user-defined) networks for the target with those for the host platform.

Steps to reproduce the issue:

1. Have a docker swarm running on Linux.
2. Create a compose file as follows.
3. Try deploying the compose file from Linux, with a command line like docker swarm deploy -c test.yaml test. (This works just fine).
4. On Windows, set up a context targeting the same Linux swarm.
5. Try to deploy the same stack on windows targeting the same linux swarm with a command line like docker -c swarm stack deploy -c test.yml test.

Describe the results you received:
The Linux-based deploy works.
The Windows-based deployment fails with the following message:

network "bridge" is declared as external, but it is not in the right scope: "local" instead of "swarm"

Describe the results you expected:
I would expect that deploying the exact same compose stack to the same swarm cluster would work the same
from both windows and Linux (expect possibly with respect to obvious things like any use of windows style paths, files having windows line endings, etc).

Presumptive cause
The code responsible for this error message attempts to check if the specified network is a user network, or
an always present system network. It uses the following code to do so:

https://github.com/docker/cli/blob/f0a21931c7e323d47ae9447e5e35d3f1b61c6bd1/cli/command/stack/swarm/deploy_composefile.go#L81-L92

Unfortunately, container.NetworkMode(networkName).IsUserDefined() seems returns information that would apply to a build of dockerd that for the same platform as the cli was built for. Thus for Windows a CLI build it only considers as built-in (i.e. non-user defined) networks those that are built in a Windows build of dockerd (for running Windows containers). That has a different set of built-in networks than Linux builds of dockerd. This even includes the WSL2 mode of Docker Desktop for Windows, which uses the normal Linux names for its built-in networks. For example windows builds of the CLI consider nat to be non-user defined, but considers host and bridge to be used defined, while Linux builds of the cli are the opposite.

I expect this issue may impact all 4 places in the cli code where container.NetworkMode(...).IsUserDefined() is used, but I've not looked into the other 3 cases that closely.

Additional information you deem important (e.g. issue happens only occasionally):
I am using the docker desktop build of the cli, (which is wrapped in compose-cli), but I'm fairly certain a clean windows build of this repo would exhibit the same behavior (I don't have a windows go environment set up to test building). I am using an ssh context, but I suspect a TCP based context for the swarm would behave the same.

The version and info outputs below are from windows while targeting the swarm context.

Output of docker version:

Client: Docker Engine - Community
 Cloud integration: 1.0.1
 Version:           19.03.13
 API version:       1.40
 Go version:        go1.13.15
 Git commit:        4484c46d9d
 Built:             Wed Sep 16 17:00:27 2020
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.13
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       4484c46d9d
  Built:            Wed Sep 16 17:01:06 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.3.7
  GitCommit:        8fba4e9a7d01810a393d5d25a3621dc101981175
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker info:

</details>
**Additional environment details (AWS, VirtualBox, physical, etc.):**

Start in cli/command/stack/swarm/deploy_composefile.go at the linked network-scope check, then inspect the other three uses of container.NetworkMode(...).IsUserDefined() mentioned in the issue. Reproduce deployment from a Windows CLI to a Linux swarm and verify that the same valid stack deploys successfully from both platforms without the incorrect external-network scope error.