Replace PathBuf-based resolution in AssetPath::resolve with URL-like segment resolver

# Objective

Replace `PathBuf`-based path resolution in `AssetPath::resolve` / `resolve_embed` with a deterministic, URL-like algorithm that operates on asset-path segments (string slices), avoiding platform-specific filesystem semantics (e.g. Windows drive letters).

This is a follow-up to concerns raised in review of #22416

## Context

`AssetPath` is not a filesystem path; it is closer to a URL-like path used by the asset framework. Today, `AssetPath::resolve` uses `PathBuf` internally for normalization / joining. `PathBuf` applies platform-specific parsing and normalization rules that are not intended for Bevy asset paths and could be a source of subtle bugs.

## Proposed change

- Implement an internal resolver that:
- treats `/` as the only separator
- resolves `.` and `..` via predictable segment stack rules
- preserves existing semantics for:
- label-only inputs (`#label`)
- leading `/` (rooted asset paths)
- explicit sources (when present)
- RFC 1808-style `resolve_embed` behavior ( [directory-relative resolution](https://datatracker.ietf.org/doc/html/rfc1808) )
- Update `AssetPath::resolve_internal` (and related helpers) to use this resolver instead of `PathBuf`.

## Acceptance criteria

- Existing `bevy_asset` path tests continue to pass.
- Add targeted unit tests covering cases where `PathBuf` can behave unexpectedly, such as:
- segments containing `:` (e.g. `C:`, `a:b`) are treated as normal segments
- backslashes `\` are not treated as separators at the asset-path layer
- `..` does not escape above root for rooted paths (if this matches current behavior)
- multiple `/` handling matches current behavior (normalize or preserve, whichever is current)
- Behavior of `resolve` / `resolve_embed` remains stable and documented via tests.

## References

- Review discussion on #22416, specifically @viridia concern about `PathBuf` usage