dotnet-svcutil generated code contains hardcoded system details

**Describe the bug**
Not a bug, but a feature request.

When the `dotnet-svcutil` tool generates a client, it hardcodes the default endpoint and references this endpoint in the default constructor. This is a problem for an organization whose policies do not permit configuration data or system identifying information in a codebase. So, when generating clients for a system, manual intervention is required in order to remove the hardcoded addresses every time the WCF service is updated. This issue is compounded for an environment with multiple WCF service/client endpoints.

**To Reproduce**
Steps to reproduce the behavior:
1. Following the WCF `dotnet-svcutil` tutorial, generate a client via `dotnet-svcutil http://contoso.com/SayHello.svc`.
2. The `AuthenticationClient` constructor sends the result of static method `GetDefaultEndpointAddress()` to the base class, which includes the hardcoded URL to the target service.

```
public AuthenticationClient()
: base(AuthenticationClient.GetDefaultBinding(), AuthenticationClient.GetDefaultEndpointAddress())
{
this.Endpoint.Name = EndpointConfiguration.BasicHttpBinding_IAuthentication.ToString();
ConfigureEndpoint(this.Endpoint, this.ClientCredentials);
}
```

**Expected behavior**
Preferably, `dotnet-svcutil` should have some kind of flag to exclude "default" configuration of the client. Ideally, if a `--do-not-generate-default-endpoint-configuration` (or similar) flag is passed to `dotnet-svcutil`, it should do the following:

- NOT generate the static method `GetEndpointAddress(EndpointConfiguration endpointConfiguration)` which contains the hardcoded URL

However, this breaks several things in the generated code, so we must also:

- NOT generate the static `GetDefaultEndpointAddress` method; and
- NOT generate the default parameterless `AuthenticationClient` constructor; and
- NOT generate the `AuthenticationClient(EndpointConfiguration endpointConfiguration)` constructor

Optionally, for applications that already have a configuration file (local.settings.json, or similar) it would be convenient to generate a namespaced configuration entity which can be read into the client. However, the suggested JSON configuration would be a greater level of effort due to the need to form a standard, as well as requiring some optional conditions.

**Screenshots**
N/A

**Additional context**
N/A