Added methods for absolute path handling in Path utility class - #19592

• Introduced isAbsolute() to check for absolute paths.
• Added makeAbsolute() to construct absolute paths based on a base path.
• Included extensive test coverage for the new methods in PathTest.

Implementation notes / discussion points

Path separators are always normalized, regardless of OS.
isAbsolute() and makeAbsolute() follow the existing behaviour of normalize()/join(): backslashes are always treated as path separators and Windows drive letters are always recognized, independent of the OS the code happens to run on.

makeAbsolute() does not resolve ./.. segments.
The result is a plain concatenation of $from and $path (see the ../config case in testMakeAbsolute), not a canonical path. This is consistent with the rest of the class: neither join() nor normalize() resolve dot segments either.
Flagging this so it reads as a scope decision, not an oversight — a proper canonicalization method would be a separate, larger addition.

$from is not validated as absolute.
Passing a relative $from to makeAbsolute() will silently produce a result that looks absolute but isn't. No other method in this class throws on invalid input, so this PR keeps that behaviour and documents the expectation in the docblock instead of adding validation/exceptions. Happy to add a guard if reviewers prefer stricter behaviour.

Edge case: bare drive letter ("C:", no trailing separator).
isAbsolute() requires a separator after the colon ("C:/"), so isAbsolute('C:') is false. A bare "C:" conventionally refers to the current directory on that drive rather than its root, so treating it as non-absolute seemed the safer default — open to discussion if a different convention is preferred.

Test coverage suggestions, if useful:

• makeAbsolute() with an already-absolute $path containing backslashes (e.g. C:\other\file.php), to exercise the "already absolute, normalize separators" branch explicitly.
• isAbsolute() with a lowercase drive letter and a drive-relative path (C:folder).

P.S. I rightly maintained the same "style" in the tests.
However, from now on, I would really encourage the use of the DataProvider and (especially) TestWith attributes whenever possible (I can do another PR for this).