There are a few bugs relating to the calculation of starting positions of implicitly typed variable declarations and their corresponding types.

* For a declaration like `final var x`, the fix for JDK-8329951 was returning a starting position incorrectly pointing to `final` instead of the `var*
* A declaration like `final var x` was correctly pointing to `final` for normal declarations, but incorrectly pointing to `var` for lambda parameter declarations.
* `JCVariableDecl.declaredUsingVar()` was incorrectly returning false for `var` variable declarations in record deconstruction patterns

Background: When a var is parsed or a variable is implicitly typed such as a lambda parameter, `JCVariableDecl.vartype` is set to null until the type can be inferred. This causes various problems when trying to determine the starting position of (a) the declaration's type, when `var` is used, because the source position of the `var` has been lost forever (especially if there are also modifiers); and (b) the starting position of the declaration itself, when there are no modifiers, because normally that's computed from the start position of `JCVariableDecl.vartype`, which is (sometimes) null.

There is a field `JCVariableDecl.startPos` which was put there to workaround problem (b), but that workaround was being applied even when there were modifiers, which is wrong. Etc.