Improve the autocomplete search

As per our discussion with dgg & dlobo, here is a quick list of issues around the autosearch. All have working code, just need to decide if all of it needs to be put in, or only some, and in what order

Issue: the autocomplete on the nav menu has serious limitations (aka it sucks): the %q% requests brings way too many contacts, the sort order is weird (eg if you search on the first name), it's not that quick if you get a big db, and the cache seems to avoid additional requests that would have retrieved more results. (can point to previous issues/forum posts is you want more details on these).

Moreover, the search backend is shared between several fields in the front office, that use different modes (eg search on the nav menu, current employer, shared address household and probably loads more here and there).

IMO: Things to improve (some are already in the svn, or have but have been reversed):

1) Query:
Following various tests with Goran & co, we came up with,

• search on q% instead of %q% (better quality result and time)
• concatenate 3 search results: q% on sort_name (works on last name, org name & household name) order by sort, %q on first_name order by first, %q on email order by email,

To make it faster, needs to update the is_deleted so it has only one value (0) instead of 0 and NULL, trivial, but need to be mentioned
Open question: the ACL is potentially very expensive and not sure how it is handled right now, quite sure it isn't taken into account in Goran's queries. Is this really an issue IF we do 2) ?

2) return less variables. since a bit ago, we return the phone and state and whatelse. It makes the search result less readable, and if it has a negative impact on the speed as soon as you got more than the handfull contacts, shouldn't be joined.

3) JSON
instead of the blob data CONCATENATE, return a json, cause that's the right thing to do.

4) use a wrapper $().crmAutocomplete
much easier, makes it cheaper as well do add on the simple search, on the current employer in a profile if the user is not anonymous and so on.
the crmAutocomplete is made so you can param it easily so instead of calling the "fast but simple" default search, you can use the complete search & filter by group/tag/country and whatever you want

Open issue?: need your help to test if it works well on joomla/alternative root/non clean url and other config

Proposal (all is implemented & working on my PC, tested with 10k dbs):

1) we keep the existing backend/front end code, so we don't fubar the existing stuff that works

2) Create a new contact/simplesearch api, with the better sql request, and parameters compatible with the contact/search

3) modify crmAutocomplete to use this api

4) replace ONLY the autocomplete in the menu to use crmAutocomplete

5) test & validate on various configurations and so on

6) migrate the other autocomplete on 3.3

X+