Adding DomainRoot causes split in core, plus additional refactorings.

In this commit many files got moved around.  See below for details on some
decisions and features already ported to the new version of the framework.

* Abstract support for BackEnd.  Each back end must implement the
  `pt.ist.fenixframework.core.BackEnd` interface (and, typically, to provide a
  subclass of `Config` that supports setting it up appropriately).  Closes #8.

* Closes #10: It was a design decision that the `DomainRoot` (DR) should be a
  part of the `fenix-framework-core` (core).  Given that the DR must be
  modelled in DML, then the core must run the DML compiler.  Thus, the DML
  compiler must be moved out of the core (because of how maven dependencies
  work).  This is accomplished in a new module `fenix-framework-dml-compiler`
  (dml-compiler).  This module also gets the `DomainObject` (DO), the
  `AbstractDomainObject` (ADO), and the default `PojoCodeGenerator` (PCJ).
  Any code generator should generate domain classes that inherit (directly or
  not) from ADO.  Any concretization of a domain model requires the
  implementation of the `getExternalId()` and `getOid()` methods (from DO and
  ADO, respectively).

* Now the core depends on the `dml-maven-plugin`, which implies that code used
  by the plugin must be moved out of the core, namely the `Project` and
  `DmlFile` classes.  This led to the creation of the
  `fenix-framework-project` module, on which the `dml-maven-plugin` now
  depends, besides depending on the dml-compiler, of course.  Additionally,
  because the core also contains the `@Atomic` annotation, this was also
  extracted and moved to the dml-compiler.  Actually, it makes sense for the
  DML compiler to be able to post-process domain classes (inject special
  constructor and process `@Atomic` annotations).

* Closes #4.  The persistent-root module was later renamed to domain-root, and
  even later it was decided to include the DR in the core.  The well-known ID
  of the root object is hardcoded and hidden in each back end through the
  implementation of `getDomainRoot()`.

* The core provides a default configuration with a default in-memory-only back
  end.  Thus, it must provide a concrete implementation of `getExternalId()`
  and `getOid()` for the DOs.  It uses a `CoreCoreGenerator` (CCG) that simply
  extends the PCJ to set the domain class root to be the
  `pt.ist.fenixframework.core.CoreDomainObject` class.  Because the CCG is
  used by the dml-maven-plugin, which in turn runs before the main compilation
  phase, the CCG must be made available in another module.  This is done in
  `fenix-framework-core-code-generator`.

* Regarding issue #13: The ANT task is now on dml-compiler, but still needs to
  be moved out of there to a separate module.

* Closes #7.  The transactional interface is not finished, but when the need
  for more changes arises, a new issue should be created.  Moreover,
  @jcarvalho is looking into this in issue #15.

* Summary of dependencies between fenix-framework modules:

  1. fenix-framework-dml-compiler: none.

  2. fenix-framework-project: none.

  3. dml-maven-plugin: 1, 2.

  4. fenix-framework-core-code-generator: 1.

  5. fenix-framework-core: 1, 2 (not yet, but will be added later), 3, 4 (via
  the plugin).