SI-6168 Retain prefix when parsing types in JVM signatures

When reading Java classfiles, the generic signatures are
used to construct the corresponding Scala type signatures.

In the enclosed test case, the field `SomeClass.f` had
the JVM signature:

    LContext<LSomeClass;>.Field<Ljava.lang.Integer;>;

The parser first (correctly) parsed the prefix as `Context[SomeClass]`.
It then looked up the type symbol for `Field` in that that type. It then
discarded the parsed prefix, and instead used the prefix from the
info of the type symbol: `Context[ParentType]`.

This commit changes the signature parser after the first `.` to
use the result of prior parsing as the prefix.

I've also included a test case with Java static inner classes,
which don't require any special treatment.

Review by @dragos (picked on account of earlier work in the area 2ea6916)

Note that partest exercises both the java source parser and classfile reader.

```
In practice, this happens in 3 steps:                                                                         
STEP1: Feed all the files to scalac if there are also non-Scala sources.                                      
       It will parse java files and obtain their expected signatures and generate bytecode for scala files    
STEP2: Feed the java files to javac if there are any.                                                         
       It will generate the bytecode for the java files and link to the scalac-generated bytecode for scala   
STEP3: (Re-)compile the scala sources so they link to the correct                                             
       java signatures, in case the signatures deduced by scalac from the source files were wrong. Since the  
       bytecode for java is already in place, we only feed the scala files to scalac so it will take the      
       java signatures from the existing javac-generated bytecode.                                            
       Note that no artifacts are deleted before this step.                                                   
```

Targeting at `master` rather than `2.10.x` as there is a (small) chance that this improvement will silently change the meaning of some existing code; we will now infer the correct specific types for calls to such methods, which could affect subsequent overload resolution etc.