Reclaim scala package

[softprops]

this relates to #526 ( specifically this comment ). The base package of the entire test hardness is scala which just happens to be the base package of scala std lib. This prevents the ability do refer to things like scala.Option within mixed java sources.

[softprops]

note this looks like a lot ( and it is ) but its exclusively renames of the test harness packaging from scala to scalarules.

[softprops]

these comments were well with the extra few seconds it took to add them. I dealt with a number of failing tests related to jars that I had to recreate using the commentary in these rules.

[softprops]

Looks like a failing scala_specs2_exception_in_initializer_without_filter test. Ill look into that.

[softprops]

@johnynek or others it looks like the builds is passing expect for one item on the build matrix which I can't tell if its related to my changes here

[johnynek]

thanks @softprops it looks like a transient download issue. restarting.

[johnynek]

thanks @softprops !

[ittaiz]

thanks!

[softprops]

Np. I think I can followup on the mixed compilation thing with a failing test case. I'll likely need to get up to speed on what's changed since I last understood the code base. In any case this exercise gave me a greater appreciation for the amount of testing in these rules. One thing may suggest is tips for contributors on getting faster turn around cycles. Rename / retest cycles for this particular pr were massive!

[johnynek]

yeah, that's good feedback @softprops. A better doc on tips for contributing would be very useful.

Also, if we could port more of the tests to be in bazel so that running them is as easy as bazel test test/... Getting negative tests inside bazel seems at least like a recursive call to bazel, something that has always made me nervous, but maybe is okay. There was some work on a bazel testing framework, and we even have a PR: #503 -- if we can expand on that, it might decrease iteration time.