[SPARK-4431][MLlib] Implement efficient activeIterator for dense and sparse vector

Previously, we were using Breeze's activeIterator to access the non-zero elements 
in sparse vector, and explicitly skipping the zero in dense/sparse vector using 
pattern matching. Due to the overhead, we switched back to native `while loop` 
in #SPARK-4129.

However, #SPARK-4129 requires de-reference the dv.values/sv.values in 
each access to the value, and the zeros in dense vector and sparse vector 
if exist are skipped in the add function call; the overall penalty will be 
around 10% compared with de-reference once outside the while block, 
and checking if zero before calling the add function. The code is branched out 
for dense and sparse vector, and it's not easy to maintain in the long term.

Not only this activeIterator implementation increases the performance, 
but the abstraction of accessing the non-zero elements in different 
vector type also helps the maintainability of codebase. In this PR, 
only MultivariateOnlineSummarizer uses new API as example, 
and others can be migrated to activeIterator later.

Benchmarking with mnist8m dataset on single JVM 
with first 200 samples loaded in memory, and repeating 5000 times.

Before change: 
Sparse Vector - 30.02
Dense Vector - 38.27

With this optimization and no local copy:
Sparse Vector - 27.54
Dense Vector - 35.13

(PS, when I did the bytecode analysis, I found that accessing the 
member variables of values and values.size require two operation. 
By having a local copy of reference to make it as single call, there is
another 8% performance gain. See 
http://stackoverflow.com/questions/6602922/is-it-faster-to-access-final-local-variables-than-class-variables-in-java for detail)

With this optimization and local copy:
Sparse Vector - 26.37
Dense Vector - 32.43


`Tuple2[Int, Double]` is specialized in Scala: https://github.com/scala/scala/blob/2.10.x/src/library/scala/Tuple2.scala, but the iterator interface still won't be high-performance for numerical computation. The iterator interface is not used in this PR, as we only need `foreach`. Then the best for us is defining `foreach` directly: 

~~~scala
def foreach(f: (Int, Double) => Unit)
~~~

( We could implement `ZippedTraversable2` but it doesn't seem to be necessary.)

or

~~~scala
def foreach(skipZeros = True)(f: (Int, Double) => Unit)
~~~

This is a private function. We can change it when we see more use cases.