dotnetup: Add verbose/diagnostic logging for troubleshooting failures

## Problem

When dotnetup encounters errors (e.g., network failures during download), the error messages often only include the outermost exception message, losing diagnostic details. For example:

```
Error: Failed to fetch release manifest: Error while copying content to a stream.
```

This doesn't tell us whether the root cause was a socket timeout, DNS failure, TLS error, task cancellation, etc. Similarly, when mutex contention occurs (`Another dotnetup process is running`), we don't log how long the wait took.

This makes it difficult to diagnose failures in CI and in user reports.

## Proposal

Add one or both of:

1. **Verbose mode** (e.g. `--verbose` or `-v` flag) that outputs detailed diagnostic information to the console, including full exception chains, timing info, and retry attempts.

2. **Log file** — always write detailed diagnostic information (including inner exception details, stack traces, timing) to a log file (e.g. in the dotnetup state directory), so that even without `--verbose`, users can share the log for troubleshooting.

### Specific items to log:
- Full exception chain (inner exceptions, not just the outermost message)
- HTTP response status codes and headers on failure
- Mutex wait duration when contention occurs
- Download retry attempts and timing
- SDK/runtime version resolution steps

## Context

Observed in CI where an E2E test failed with a network error during runtime download. The mutex contention message appeared beforehand but we couldn't determine whether the two were related because the error lacked detail.