[Feature] Don't require azure.yaml

## Problem

`azd` requires an `azure.yaml` file to function, even for infra-only projects that have no application services. Users who only want to run `azd provision` with an `infra/main.bicep` must still create and maintain an empty `azure.yaml`. This adds friction for:

1. **Infra-only projects** — Teams using azd solely for Bicep/Terraform provisioning with no app code
2. **CI/CD pipelines** — Build systems that provision infrastructure separately from deployment, where source code isn't present (see #1957)
3. **Lightweight adoption** — New users trying azd for the first time; requiring a config file before any command runs creates onboarding friction
4. **Ephemeral/scripting** — Using azd as a CLI tool in scripts or one-off scenarios where a project file feels heavyweight

## Current Behavior

- `azdcontext` walks up the directory tree looking for `azure.yaml` / `azure.yml` — returns `ErrNoProject` if not found
- `project.Parse()` fails if the file content is empty
- VS Code and VS extensions use `azure.yaml` existence to discover and activate azd projects
- `.azure` directory is only created as a side effect of `azd init`, not independently

## Proposed Approach

A convention-based fallback when no `azure.yaml` is present:

1. **Convention detection**: If `azure.yaml` is absent but `infra/main.bicep` (or `infra/main.tf`) exists, treat the directory as an azd project with default/minimal configuration
2. **Synthesize in-memory config**: Generate a `ProjectConfig` with `name` derived from the directory name (matching `azdcontext.ProjectName()` behavior) and default infra settings — no file written to disk unless the user explicitly runs `azd init`
3. **Fallback project root**: Use the directory containing `infra/` as the project root. Optionally also recognize `.azure/` as a project root marker (for projects that have run `azd init` previously but removed `azure.yaml`)
4. **Extension point**: Consider whether this should be a core behavior or opt-in via an extension

## Key Design Decisions

- [ ] Should azd auto-create `azure.yaml` on first use (implicit init) or synthesize config in-memory only?
- [ ] Should `.azure/` directory alone (without `azure.yaml`) be sufficient to identify a project root?
- [ ] What commands work without `azure.yaml`? (`provision`, `down`, `env` likely yes; `deploy`, `package`, `restore` likely need services defined)
- [ ] How do VS Code / VS extensions adapt? They currently key off `azure.yaml` for activation

## Impact

- `pkg/environment/azdcontext/azdcontext.go` — `NewAzdContextFromWd()` needs fallback logic
- `pkg/project/project.go` — `Load()` / `Parse()` need to handle missing/absent file gracefully
- `cmd/container.go` — DI container wiring that depends on project resolution
- VS Code extension (`azure-dev` extension) — needs parallel detection strategy
- ~80+ files reference `azure.yaml` in error messages, comments, or logic

## Acceptance Criteria

- [ ] `azd provision` works in a directory with `infra/main.bicep` but no `azure.yaml`
- [ ] `azd down` works in the same scenario
- [ ] `azd env` commands work without `azure.yaml`
- [ ] Commands that require services (`deploy`, `package`) give a clear error explaining services must be defined in `azure.yaml`
- [ ] VS Code extension still activates for convention-detected projects (may be a separate PR)
- [ ] Existing projects with `azure.yaml` are unaffected (backward compatible)
- [ ] `azd init` still creates `azure.yaml` when run explicitly