Orphan razor.css cleanup can be improved

[ysmoradi]

Issue Description

Summary:
This proposal is to enhance the DeleteUnmatchedRazorCss MSBuild target to make it more robust. The change involves modifying the condition for deleting orphaned .razor.css files to check for the existence of the corresponding .razor component file, rather than a .razor.scss file.

Current State:
The current DeleteUnmatchedRazorCss target effectively cleans up orphaned .razor.css files for our SCSS-based workflow. It works by checking if a corresponding .razor.scss file exists and deleting the .razor.css if the .scss file is missing.

Opportunity for Improvement:
While this logic serves our primary workflow, it is tightly coupled to the use of SASS. It makes the assumption that every .razor.css file must originate from a .scss file. This could lead to issues if a developer decides to write plain CSS for a component directly in a .razor.css file, as the build process would incorrectly identify it as an orphan and delete it.

Proposed Solution:
By changing the condition to check for the existence of the base .razor file (%(RecursiveDir)%(FileName)), we make the logic more accurate. A scoped CSS file is only truly an orphan if its associated component has been removed.

Benefits:

• Increased Robustness: The .razor file is the definitive source of truth, making the cleanup logic fundamentally more correct.
• Greater Flexibility: This change allows developers to use plain .razor.css files without them being accidentally deleted by the build process.
• Future-Proofing: It makes the build system less dependent on a specific pre-processor, future-proofing it against changes in our styling toolchain.