Deleted profile for compiling with Scala 2.9

Dropping 2.9 support.
`scala.version` property now set in the corresponding profile

Let's have one single place where the `scala.version` is assigned.
This is useful also for the build kitty (which I'm setting up for
validating PRs opened on the scala-refactoring repo).
Deleted `repo.scala-ide` property because it isn't used

This property was used to retrieve the OSGi-fied scala bundles from the
Scala IDE p2 repository. However, in SHA:
8b5efd255fa65dc88710d7d54e7275ce8f225676 we moved the build to use the
plain Scala JARs (because they are already OSGi ready), making the
`repo.scala-ide` effectively unused.
Merge pull request #39 from dotta/issue/clean-up-pom

Issue/clean up pom
Prevent `this` with transparent position to be indexed

This change was needed to successfully run all scala-refactoring test
based on a Scala compiler that contains a fix for
https://issues.scala-lang.org/browse/SI-4287 (PR for this ticket will
follow shortly).

The fix for the compiler mentioned above affects the positions assigned
to synthetic constructor Trees, and that was causing the test
`MoveClassTest.copyrightHeaderIsMovedAlong` to fail because an
additional (and unexpected) `import org.com.pkg.B` clause was being
inserted in the refactored source.  While debugging the failing test,
I've compared the content of the `CompilationUnitIndex` before and after
the changes made in SI-4287, and noticed that an additional reference
for the `class B` symbol to the `this` tree was being cached while
traversing the `B.super.<init>()` Apply tree, in `B` syntehtic
constructor.

Which is why I thought that the `this` reference should be stored in
the index iff the position is an opaque range position (i.e., the
reference existed in the original source), while it should be skipped
if it is a transparent one.

That also made me wonder if, as a general rule, trees with a non opaque
range position should not be inserted in the index. As Mirko (Stocker)
pointed out in [this
comment](https://github.com/scala-ide/scala-refactoring/pull/38#issuecomment-30416000),
this should be indeed the case. However, it is likely that by doing so
some of the scala-refactoring tests may be failing because "positions
aren't always of the correct type" (implying that Scalac doesn't always
produce trees with correct positions - which is indeed very possible).
This is something we should investigate further, but it's out of the scope
of this commit. Nevertheless, this discussion validates the change carried
out in this commit.

Below follows the result of printing the tree produced by the test in
`MoveClassTest.copyrightHeaderIsMovedAlong`, before and after fixing
SI-4287. It is worth noting that the positions of the trees in `B`
synthetic constructor have changed, causing the issue described in the
second paragraph of this commit.

Before fixing SI-4287
--------------------
```
[[syntax trees at end of                     typer]]
[21:82]package [29:36]org.com {
  [37:82]package [45:48]pkg {
    [50:57]abstract trait A extends [57:57][59]scala.AnyRef;
    [59:82]class B extends [76:82][82]scala.AnyRef {
      [77:81]<paramaccessor> private[this] val a: [77]org.com.pkg.A = _;
      [82]def <init>([77]a: [80]<type: [80]A>): [76]org.com.pkg.B = [82]{
        [82][82][82]B.super.<init>();
        [76]()
      }
    }
  }
}
```

After fixing SI-4287
---------------------
```
[[syntax trees at end of                     typer]]
[21:82]package [29:36]org.com {
  [37:82]package [45:48]pkg {
    [50:57]abstract trait A extends [57:57][59]scala.AnyRef;
    [59:82]class B extends [76:82][82]scala.AnyRef {
      [77:81]<paramaccessor> private[this] val a: [77]org.com.pkg.A = _;
      <77:81>def <init>(<77:81>a: [80]<type: [80]A>): [76]org.com.pkg.B = <77:81>{
        <77:81><77:81><77:81>B.super.<init>();
        <77:81>()
      }
    }
  }
}
```