This fixes a critical bug meaning that using many_many fields in full text searching would have always failed.
the $singleton->many_many() lookup returns an array() of many-many components, however the line $class = $manyMany[0] is wrong, as the first value of the array is always the $dataClass (parentClass), not the otherClass (childClass).
Changing this to $class = $manyMany[1] fixes this bug.
Its impossible for SearchUpdater#handle_manipulation to figure out the difference
between writing to a table-less class (like Page if theres no $db set) and the
table-having parent (like SiteTree) because it only examines the DB manipulation
This meant if you tried to index Page without setting $db fields, only subclasses
that did have $db fields would be indexed
We cant fix, but we can throw an error if you try to do that
process_dirty_indexes wasnt saving variant state or restoring or exit, because
I thought it was only called at the end of a request and so didnt need to
But tests call it regularly throughout a request. So now its clean
and safe to call when-ever
When the module was called solr we could call SearchUpdater::bind_manipulation_capture in _config.php, because
solr/_config.php was included after mysite/_config.php. This isnt true when the module is called fulltextsearch
Instead we hook into the new RequestProcessor in 3.0 to make the manipulation capture. We also make
bind_manipulation_capture re-callable, so you can call it any time you need to make sure.
