Escaped placeholders are evaluated if the PropertySource has placeholder support

[snicoll]

This is a follow-up of #34315

Consider the following example:

prop1=value1
prop2=value2\\${prop1}

prop2 should evaluate to value2${prop1} as the placeholder has been escaped.

This works for basic PropertySource implementations, but if the source is backed by PropertySourcesPlaceholderConfigurer the escaped ${prop1} is still evaluated even though it should not be.

[snicoll]

So the problem is that PropertySourcesPropertyResolver contains a nested PlaceholderResolver itself. When prop2 is requested, it goes to a first round where it is resolved to value2\\${prop1} which is then parsed as value2${prop1} where the escaped character is removed and ${prop1} is considered as a litteral string.

The problem is that this resolved value come back to the original parser. Rather than seeing value2\\${prop1} it gets value2${prop1} and it resolves the nested placeholder since it has lost its escape character.