[5.8] Add view path to end of compiled blade view

[driesvints]

This re-adds the functionality that was added in #27544 and #27976 and removed again in 33ce7bb.

The main difference with this approach is that it takes into account the issue from #27996. By not introducing a newline it doesn't changes anything to the rendered view itself. The path is now applied as the final piece of code. This doesn't allows IDE's to rely on it being the last line though. Instead we use /**PATH and ENDPATH**/ to make sure we have an easy way for the IDE to pick up the path it needs.

@bzixilu this would provide a "unique" way for PHPStorm to pick up the path. I suspect changes on PHPStorm's end are needed to make this work. But you could, in theory, always rely on the path being between the /**PATH & ENDPATH**/ comment blocks. Would this approach help?

Replaces #28099

[fitztrev]

Suggested change

	$contents .= "<?php /**PATH {$this->getPath()} ENDPATH**/ ?>";
	$contents .= "<?php #PATH {$this->getPath()} ENDPATH# ?>";

Maybe just a slightly different comment syntax for aesthetics and shorter regex pattern?

[driesvints]

Could be possible yes. Gonna wait what @bzixilu says.

[fitztrev]

Was the cache filename as a base64 encoded string instead of a sha1 (suggested by Taylor) decided against?

[driesvints]

@fitztrev it's still on the table but in my eyes a more overkill solution than the simple solution this PR provides.

[bzixilu]

Hi all, thank you for taking care of the debug feature.

Both suggested variants - encoding of a view path into a compiled view filename as well as the movement of the debug info to the line above - will work to provide a debug info to PhpStorm since we can in both cases somehow retrieve a view path from a compiled view. Each of the proposed solutions requires changes from our side that we will be able to provide only in PhpStorm 2019.1.1. But that is ok. Completely losing the feature is much worst.

Below are a couple of thoughts about base64 encoding.

Base64 encoding works in both directions, so in the future, we will be able to provide the additional info, e.g., line mappings that can also be easily decoded for the debug needs (I would avoid one-way encryption for our purposes).

But there are a few things that should be taken into account if you choose this way:

1. Length of a message encoded with base64 depends on initial message length (1.3 times longer). If we want to provide more info in the future, it may lead to exceeding the limit on the length of the filename in Windows, so the length of the message should be under control.

2. The standard base64 encoding may use "/" sign in the encoded message, but it is forbidden sign in the filename in Linux and Windows. So some modified base64 encoding should be considered.

Maybe there is something else that didn't come up to my mind.

To summarize, I would vote for the human-readable comment like you've implemented in this PR.

[sisve]

This looks like it produces invalid files for blade views ending with an open php block. I believe the fix is to check if there's an open php block, and close it before appending the path comment.

To be clear, here's an example file of what I mean:

<?php echo $html

This file becomes

<?php echo $html<?php /**PATH foo ENDPATH**/ ?>

[driesvints]

@sisve thanks for making me aware. I've spent some time today working on a fix: #28141