refactor several get concept routines to new concept name selection criteria

There is a PRIVATE method in ConceptServiceImpl,
getConcepts(String,Locale,boolean,List<ConceptClass>,List<ConceptDatatype> : List<Concept>
which is called by 3 public methods in ConceptServiceImpl
getConceptByName – exact match
getConceptsByClass – the routine that was throwing the error
getConceptsByName – fuzzy match
and which delegate to 2 corresponding methods in the DAO and HibernateDAO ("the problems").
At the same time, ConceptServiceImpl has "the big kahuna", getConcepts(String, List<Locale>, boolean, List<ConceptClass>, List<ConceptClass>, List<ConceptDatatype>, List<ConceptDatatype>, Concept, int, int) : List<ConceptSearchResult>

At the Hackathon, it was decided to have the 2nd and 3rd routines delegate to the big kahuna rather than to the private getConcepts, and to give getConceptByName its own DAO routine. However, it was discovered that the behavior of the routine did not match the behavior described in ConceptService:getConceptByName, even though the unit tests passed. Furthermore, the "shoulds" did not match the current selection criteria for "best" concept names. This method is called by 53 other routines, mostly in input and reporting functions.

We need to decide upon the desired functionality, determine the impact of any change on the routines which call it, and do the right thing.

See related issue TRUNK-2730.