Fix Go to Definition to a source-generated file

[jasonmalinowski]

#47047 changed the logic for the file name and path we generate, but we were no longer ensuring the temporary directory existed prior to trying to create the file within it.

[davidwengier]

Should there be some code somewhere that checks if the new option is turned on, and navigates to the real files that the compiler created?

[chsienki]

Weird, I did test this, but it went through a bunch of iterations so I guess it got broken after the fact? Anyway, good catch and thanks for the fix.

[jasonmalinowski]

@davidwengier: @chsienki and I discussed this a bit and we decided to keep this as is for now. There's a few challenges:

1. The files may not exist in the first place if the user doesn't have them on.
2. The files may exist, but may be stale since they're from the last saved build. We could totally do our dynamic file experience atop these files, but then it might get confusing because if you're really trying to look at the generated result from the prior build you're not getting what you want.
3. If you want to place breakpoints in a generated file, is it living in the IDE managed versions or the compiler versions? Or both? Or something else...?

So we decided that the IDE does magic and only does magic, and the compiler only does regular outputted files and we don't get in the way. I imagine that we might do some heuristics down the road where we try to use the prior generated results in the IDE to speed things up, but we'd still use our file identity to avoid the other issues above.

[jasonmalinowski]

@chsienki: if I recall, I think there was some code review feedback you might have tried addressing which tried simplifying the path generation logic because we were otherwise generating a path and then splitting it a part again. I'm thinking this broke then.