Improve handling of "k"

MZ just added getK() and setK() to the kNN model. This brings up some interesting issues:

1. I can't think of a case where k == 2 is better than k == 1. Disallow it?
2. Ties go to the first class found. Find a better metric? Distance? Average distance?
3. If setK() asks for a k that is greater than the current number of neighbours, then k is set to the number of neighbours. Maybe kNN should remember the number that the user requested so that k can be increased if new neighbours are added?
4. Using getK() and setK() in a modelSet required casting a baseModel* down the inheritance chain. Is this bad design? How will this work if more parameters are exposed in more models?

This issue should probably be broken up into sub-issues.