Added integration tests for add/remove interface from LR Actions.

Just added a call to them in the chassis capability integration test calling all chassis actions.
This patch also enables this test. Failing action (set encapsulation) has been moved to another test, which remains ignored.

Asserts have been changed to produce more descriptive errors.
Merge pull request #44 from gbehrmann/feature/close-jpa-entitymanager

Replace Dynamic JPA with Aries JPA
Refactor OSPF tests and add base class
Change the syntax of the GRE and OSPF-in-router commands.
Merge pull request #51 from adrian-rosello/feature/script-update

Develop
Merge branch 'ospf-tests-refactor' of git://github.com/jordi-puig/opennaas into develop
Merge pull request #50 from jordi-puig/ospf-tests-refactor

OSPF test refactor and add base class.
Remove old karaf commands for adding and removing interfaces from a LR.

CreateLogicalRouterCommand has been updated to use AddInterfaceToLRAction to add interfaces to the newly created LR,
instead of using AddInterfaceCommand (which has been removed).

A test for AddInterfaceCommand failing when LR was activated has been removed, as this check should not be done in the command, but during action execution.
Check interface exists in Add/RemoveIterfaceFromLRActions.

AddInterfaceToLRAction executeListCommand method has also been refactored for better reading.
Merge branch 'develop' of git://github.com/dana-i2cat/opennaas into develop
Merge branch 'feature/netqueue-capability' of git://github.com/jordi-puig/opennaas into develop
persistence: Replace Hibernate with OpenJPA

Hibernate is known to be difficult to use in an OSGi context, partly
because it isn't packaged as a bundle and thus requires repackaging.

This patch replaces Hibernate with OpenJPA in OpenNaaS. OpenJPA is
available as a bundle and thus doesn't require repackaging.

Several OpenNaaS classes made explicit use of the Hibernate API. This
patch changes those classes to use the JPA API when possible. In one
case the OpenJPA API needs to be used directly: OpenNaaS's DAO
interface makes use of query by example and this functionality is not
available in JPA 2.

Access to the JDBC driver is always challenging in an OSGi context.
Previously we added a dynamic-import to our repackaged Hibernate
bundle. This allowed it to load the JDBC driver. The Aries JPA
recommended approach is however to configure the persistence.xml file
to lookup a data source through JNDI. Using this mechanism, the JDBC
driver is loaded by our opennaas-core-resources bundle, which publishes
the data source as an OSGi service. Thus no dynamic import is required.
This also has the benefit that it becomes easier to inject
configuration values when setting up the data source (should we wish to
do so in the future).
Merge branch 'develop' of git://github.com/dana-i2cat/opennaas into feature/addInterfaceToLR-moves-all-interface-config

Conflicts:
	manticore/tests/integration/net.i2cat.mantychore.tests.capability/src/test/java/net/i2cat/mantychore/chassiscapability/test/ChassisCapabilityIntegrationTest.java
	manticore/tests/sprints/sprint0_2/src/test/java/mantychore/ConfigureLRTest.java

Conflicts resolved.
All tests pass.
OSPF Capability for the network resource skeleton.
Merge pull request #52 from gbehrmann/feature/use-openjpa

Feature/use openjpa
Use assertEquals whenever possible and static imports in ChassisCapabilityIntegrationTest.
Added script to test Add/Remove interface to logical router.

Two other scripts have been updated, as they contained errors.
Add static route capability, test and karaf command.
http://jira.i2cat.net:8080/browse/OPENNAAS-235
resources: Fix partial remove of active resources

The following steps lead to inconsistent state:

1) Create resource
2) Start resource
3) Remove resource (it launches an error, as expected)
4) Stop resource
5) Remove resource -> ERROR.

The expected behaviour in 5) is that the resource can be removed.

The problem is caused by OpenNaaS removing the database entry
for the resource before checking whether the resource is active.
This means the resource is partially removed in step 3 even though
it is active. Step 5 fails because the resource cannot be removed
from the database as it was already deleted once.

Ideally the complete remove operation would be a single database
transaction, but implementing this would require quite a number
of changes to how we deal with persistence.

Instead this patch simply reorders the code:

1) Check that resource is INACTIVE
2) Remove from internal data structures
3) Remove from database
OSPF Capability service for the network sresource exported.