[Core] Added move operations to class Flags

[avdg81]

📝 Description
The aim of this PR is to make class Flags moveable. So far, it wasn't, since it explicitly defined the destructor and the copy operations (i.e. the copy constructor and the copy assignment operator). As a result, the move operations are not automatically supplied by the compiler (and thus we miss out on an optimization opportunity, since "moves" will become copies). For those who need a refresher on this topic, Howard Hinnant gives a very clear explanation in one of his presentations. In particular, starting from 13:21 he explains under which circumstances special members are provided by the compiler (and when they are not).

Since Flags is the base class of many other classes, those classes in turn are non-moveable, too. However, we don't see a fundamental objection against making Flags moveable. In fact, when it becomes moveable, other classes can be made moveable as well. To limit the scope of this PR as much as possible, we haven't touched any other classes. We may want to do that in follow-up PRs.

🆕 Changelog

• Use = default for special member functions (i.e. the default constructor, the (virtual) destructor, the copy constructor, and the copy assignment operator) rather than writing down the code that the compiler can generate for us. Note that we are using the "Rule of Five" here, since we need a virtual destructor. And, as Howard Hinnant explains, when a destructor is user-declared, the move operations (i.e. the move constructor and the move assignment operator) won't be declared. That's why we explicitly declare them here (including our request to the compiler to provide default implementations for them).
• The data members mIsDefined and mFlags are initialized in-class, and they are explicitly default-constructed. See this rule in the C++ Core Guidelines of why this is a good idea (the text below has been quoted from this rule):

Beware that built-in types are not properly default constructed:
(...)
Statically allocated objects of built-in types are by default initialized to 0, but local built-in variables are not. (...)
Assuming that you want initialization, an explicit default initialization can help:
(...)

[avdg81]

Just a friendly reminder to @roigcarlo and @pooyan-dadvand that we would like to have your opinion on this PR. Thank you.

[avdg81]

Just another friendly reminder to @roigcarlo and @pooyan-dadvand that we would like to have your opinion on this PR. Thank you.

[roigcarlo]

Hey we have taken a look with @pooyan-dadvand and we have nothing against it. 👍