[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


Okay, the issue is in the anonymous function. Basically, scala will convert primitive index: Int and value: Double into boxed object in order to have them in tuple. In my testing dataset, there are so many zeros explicitly, and even those values with zero have to be converted to tuple before we do the `if statement`. That's why it's dramatically faster if we do the `if statement` before calling the anonymous function. 

Changing the signature of `foreach` into 

    def foreach[@specialized(Unit) U](f: (Int, Double) => U)

to take two primitive variables will solve this problem, but it will not comply the interface of `foreach`.