Applies the constraints articulated in compose-spec/compose-spec#314 for
project names from `COMPOSE_PROJECT_NAME`, the project dir, or the
working dir.

Before this change, the constraints applied only when using `docker
compose -p` or the `name:` config file property. Non-normalized project
names from `COMPOSE_PROJECT_NAME`, the project dir, or the working dir
were still allowed, which `docker compose` would then normalize.

The constraints are enforced by:

- `cli.ProjectFromOptions()` setting `withNamePrecedenceLoad()` as an
  option to `loader.Load()`.
- `loader.Load()` applies `withNamePrecedenceLoad()`, which tries to get
  the project name from the command line options, then
  `COMPOSE_PROJECT_NAME`, then the project or working dir.
- `withNamePrecedenceLoad()` calls `loader.Options.SetProjectName()`,
  which now also saves the original name as well as the normalized name.
- `loader.Load()` then calls `loader.projectName()`, which reads the
  project name from the config file(s) if it's not already set.
- `loader.projectName()` then applies the new
  `CheckOriginalProjectNameIsNormalized()` function extracted from
  `cli.WithName()`.

Only a handful of test cases required updating in `cli/options_test.go`.
These test cases were checking that invalid project names were rejected
by `cli.WithName()`, but that `cli.ProjectFromOptions()` would normalize
them. Now `cli.ProjectFromOptions()` rejects them with the same error.

There's no need for new test cases specifically for
`COMPOSE_PROJECT_NAME` or directory-based project names, because the
`CheckOriginalProjectNameIsNormalized()` function is applied regardless
of the source. Other existing test cases are validating that
`cli.ProjectFromOptions` does also use `COMPOSE_PROJECT_NAME` or
directory names when necessary.

Closes compose-spec#363.

Signed-off-by: Mike Bland <mbland@acm.org>

After applying package name constraints uniformly in the previous
commit, cli/options_windows_test broke on Windows with:

```
--- FAIL: TestConvertWithEnvVar (0.00s)                                                                                                                              options_windows_test.go:35: assertion failed: error is not nil: "\\" is not a valid project name...
```

This is because the `TestConvertWithEnvVar` test was setting the working
directory as `C://`. No other mechanism defined the package name,
causing the non-normalized package name to be `/` and the normalized
package name to be ``.

Technically, this is exactly what we want: The root directory
_shouldn't_ be used for the project name, which will be empty. This
violates the new `^[a-z0-9][a-z0-9_-]*$` package name constraint.

As a result, the solution is to update the working directory to
`C:/working-dir/` and to adjust the expected results accordingly.

Signed-off-by: Mike Bland <mbland@acm.org>