Fix self-move-assignment use-after-destroy in RE2::Set and FilteredRE2

[Alb3e3]

Fixes #615.

RE2::Set::operator=(Set&&) and FilteredRE2::operator=(FilteredRE2&&) implement move-assignment with the destroy-then-placement-new idiom:

this->~Set();
(void) new (this) Set(std::move(other));

This is undefined behavior when this == &other (self-move-assignment): the destructor runs first and releases the object's owned regexes (Regexp::Decref() for Set, delete for FilteredRE2), and the move constructor then reads from the just-destroyed object. Self-move-assignment can arise through aliased references or library operations that are permitted to self-assign.

Observed effect: under libstdc++ the object is left destroyed and empty, so its compiled state is gone and Match()/AllMatches() silently returns wrong results; on other implementations the same UB can manifest as a double-free or crash.

Fix: add the standard self-assignment guard to both operators:

if (this == &other)
  return *this;

Tests: extend the existing Set.MoveSemantics and FilteredRE2Test.MoveSemantics with a self-move-assignment case, written through an aliased reference to avoid a -Wself-move diagnostic, asserting the object is unchanged and still usable. Without the guard these fail (the object is emptied); with it they pass.