Dynamically determine code mapping as last resort

I have seen a Java example where my three levels of stack trace root are not sufficient. Let me explain.

Consider these frames:
* `com.example.foo.a1.bar` -> `com/example/foo/**a1**/src/main/java/com/example/foo/a1/bar.java`
* `com.example.foo.a2.baz` -> `com/example/foo/**a2**/src/main/java/com/example/foo/a2/baz.java`

We automatically create this code mapping based on the first frame:
* Stack trace root: `com/example/foo/`
* Only 3 levels
* Source code root: `com/example/foo/**a1**/src/main/java/com/example/foo/`

Using this code mapping for both frames will create these paths:
* `com/example/foo/**a1**/src/main/java/com/example/foo/a1/bar.java` -> Correct
* `com/example/foo/**a1**/src/main/java/com/example/foo/a2/bar.java` -> Incorrect

In our current implementation, we match the code mapping, attempt to fetch the file and give up if we can't find the file, however, we could attempt determining the code mapping as a last resort and we would find the file (even if we don't store the code mapping.

The issue that shows this problem is group ID: 6851801127

Start by reproducing group ID 6851801127 and locating the code-mapping resolution path used when fetching source files. Check how a failed lookup for the mapped path can trigger a last-resort mapping attempt. Done means both a1 and a2 frames resolve to their corresponding source paths without requiring a stored mapping.

Written by the indexing model from the issue text.