Editor placeholders probably shouldn't be errors at parse time

### Description

If you parse editor placeholders using string literals (e.g., `let x: ExprSyntax = "<#a#>"), it succeeds but you get a bunch of noise in the system logs (or in the debugger console, if running it there) from this function that generally logs parser errors from string literals: https://github.com/swiftlang/swift-syntax/blob/9453f46fd0695522b3ed2833adba95da45fe9b04/Sources/SwiftSyntaxBuilder/SyntaxParsable%2BExpressibleByStringInterpolation.swift#L63. That's only suppressible using a testing SPI.

However, I'd like to argue that editor placeholders shouldn't be errors that come from the _parser_. Since editor placeholders are treated as if they were identifiers (`DeclReferenceExprSyntax` nodes) during parsing, we should be allowed to have them in the AST without triggering error scenarios. swift-format already has code to identify these errors and downgrade them because we want to be able to format code in the IDE that is syntactically valid but for placeholders still in the source.

But a more interesting use case would be building syntax tools that actually use placeholders intentionally. For example, you could imagine writing a refactoring API that transforms ASTs from one shape to another, using placeholders as a way of extracting and then substituting nodes into a "spec": something like `foo(a: <#a#>, b: <#b#>)` to `foo(a: <#a#>).bar(b: <#b#>)`. It would be nice to parse those with `ExprSyntax(stringLiteral:)` without triggering the error logging.

For users who want to forbid placeholders (like the compiler itself), a simple visitor could be provided that reports the locations of any `DeclReferenceExprSyntax` nodes that look like placeholders, which could be handled by _that_ tool's own error reporting, removing the error itself from the core lexer/parser.

Thoughts?

### Steps to Reproduce

_No response_