Created velocity templates to add/remove tagged ethernet encapsulation and set vlan-ids

Tagged ethernet encapsulation is set in junos config in a different way deppendeing on the interface type.
This encapsulation is allowed only in physical eth interfaces and in logical lt interfaces.
- In physical eth interfaces, a <vlan-tagging> tag is used
- In logical lt interfaces, an <encapsulation> element with "vlan" value is used. It has to be noticed that
this <encapsulation> element is the same used to specify plain ethernet encapsulation (using "ethernet" value).

VlanId can be set only in logical interfaces.
A <vlan-id> element with desired vlanId value is used.
Created actions to set/remove tagged ethernet encapsulation, and set vlan-id.
Added commands to add/remove tagged ethernet encapsulation and set vlan-id.
Fixes in taggedEthernetEncapsulation templates.

- Close an unclosed "if" tag.
- Do not set encapsulation type in setVlanIdInLT template.

Templates have been also copied to velocity templates bundle.
Replace typed encapsulation commands for generic setEncapsulation and setEncapsulationlabel ones.

A new approach for managing encapsulation is taken.
Now there are only two commands to manage encapsulation.
- SetEncapsulationCommand, whitch sets the type of encapsulation used in an interface.
- SetEncapsulationLabelCommand, whitch sets the label for current encapsulation type in given interface.

Currently, there are two supported types for setEncapsulationCommand:
- None: use no encapsulation.
- Tagged-ethernet: Use tagged ethernet encapsulation.

With no encapsulation, set label fails.
With tagged-ethernet, set label launches setVlanId with provided label, hence, label is checked to be a valid vlan-id [0..4096)

A temporary hack has been introduced in ChassisCapability to launch appropiated typed set encapsulation action.
This hack should be removed when ChassisCapability gets it's own interface.
Added checks to setEncapsulation actions.

Note: Checking an interface exists in the router is not yet possible.
Right now, we only can check interface exists in the candidate, but that's not what we want:

An interface is removed from the configuration when it has nothing configured.
That is a typical case when setting encapsulation, as interface may have no encapsulation nor units.
Unless this interface contains further configuration (description, or whatever else) it will not appear in candidate.

For this reason, setEncapsulation actions do not check an interface exists or not,
 and when executed, they create such interface in the configuration.
Update tests for passing with new checkings.

Some tests have been disabled, because mock does not filter the configuration.
Merge branch 'develop' into feature/set-encapsulation-in-eth

Conflicts:
	manticore/bundles/net.i2cat.mantychore.actionsets.junos/src/main/java/net/i2cat/mantychore/actionsets/junos/ActionConstants.java
	manticore/bundles/net.i2cat.mantychore.actionsets.junos/src/main/java/net/i2cat/mantychore/actionsets/junos/ChassisActionSet.java
	manticore/bundles/net.i2cat.mantychore.actionsets.junos/src/test/java/net/i2cat/mantychore/actionsets/junos/actions/test/chassis/ConfigureEncapsulationActionTest.java
	manticore/bundles/net.i2cat.mantychore.capability.chassis/src/main/java/net/i2cat/mantychore/capability/chassis/ChassisCapability.java
	manticore/bundles/net.i2cat.mantychore.capability.chassis/src/main/java/net/i2cat/mantychore/capability/chassis/shell/SetEncapsulationCommand.java
	manticore/bundles/net.i2cat.mantychore.capability.chassis/src/main/resources/OSGI-INF/blueprint/core.xml

Conflictssolved by merging changes to moved files.
Merge branch 'develop' into feature/set-encapsulation-in-eth

Conflicts:
	extensions/bundles/router.capability.chassis/src/main/java/org/opennaas/extensions/router/capability/chassis/ChassisCapability.java
	extensions/bundles/router.capability.chassis/src/main/java/org/opennaas/extensions/router/capability/chassis/shell/SetEncapsulationCommand.java

Conflicts resolved.
Refactored ProtocolSessionManager.

A part from an interal refactor and reordering of methods,
a method in the interface has been renamed.

It happened that there were 3 methods called obtainSession*:
- two of them tryed to get an existing session and created a new one if there was none,
- but the other one (obtainSessionById) returned an exception when failed to get en existing session.
This third method has been renamed to getSessionById, with no functional changes, to avoid confusion.

Additionally, some exception messages have been changed.

The only functional change is the assumption that there is only one protocolSession per registered context.
This assumption is taken into account when unregistering a context, as we stop looking for protocolSessions associated with it when we find the first one.
More refactor in ProtocolManager and ProtocolSessionManager.

- ProtocolManager is now unaware of sessions, and thus it does not treat with them.
Destroying sessions when a ProtocolSessionManager is removed, is hidden in unregisterContext call.

- ProtocolManager in unaware of the internals of ProtocolSessionContext.
To unregister a context, a new method accepting context itself as a parameter has been created in ProtocolSessionManager.

- GetAllSessionFactories method has been renamed to getAllSupportedProtocols, that better express it's meaning
Include ProtocolSessionManager creation/destruction in resource lifecycle.

Having them decoupled, may lead to sessions not being closed until opennaas is closed,
as described in OPENNAAS-255 issue (http://jira.i2cat.net:8080/browse/OPENNAAS-255)

This patch causes ResourceRepository to create a ProtocolSessionManager when a resource is created,
and destroy it when the resource is removed.

Sessions are destroyed when destroying the manager, due to previous commits.
Fix bug in getProtocolSessionManagerWithContext().

Now it always return a protocolSessionManager with given context,
either a new manager is created or an existing one is used.
Refactored AbstractActivator.

It now throws ActivatorException instead of a generic Exception.
It also resuses a method to found a service using ServiceTracker, instead of ducplicating code.
Update ResourceRepository to create and destroy sessions when resource is created/removed.

ResourceRepository is responsible of synchronizing resource lifecycle with protocolSessionManager one.
- It creates a protocolSessionManager for the resource when the resource is created.
- It destroys the protocolSessionManager for a resource, when the resourceis removed.
- It also creates one session per registered context when a resource is started, if it does not already exists.
 (This assures a single session per each registered context is available after a starting the resource.)
- It also destroys all sessions of a resource when the resource is stopped.
 (This assures no session is available after stopping the resource.)

This patch adds session creation/deletion when resource is started/stopped.

It also fixes a bug when rolling back from deactivateResource.
The bug caused bootstrapper and capabilities to be reseted even if deactivate failed, producing an unusable resource.
Patched code makes this reset only when deactivate is succesfull.
Add test to check ProtocolSessionManager and Resource lifecycle is the same.

ResourceRepository is responsible of synchronizing resource lifecycle with protocolSessionManager one.
- It creates a protocolSessionManager for the resource when the resource is created.
- It destroys the protocolSessionManager for a resource, when the resourceis removed.
- It also creates one session per registered context when a resource is started, if it does not already exists.
 (This assures a single session per each registered context is available after a starting the resource.)
- It also destroys all sessions of a resource when the resource is stopped.
 (This assures no session is available after stopping the resource.)

This patch creates a test to check behaviour explained above is followed.
Improve output of the "resource:list --all" command.
Merge pull request #98 from isartcanyameres/feature/fix-protocol-commands

Feature/synchronize ProtocolSessionManager's and Resource's lifecycle
Merge pull request #101 from jordi-puig/task/opennaas-250/output-resource-list

Task/opennaas 250/output resource list
Removed duplicated velocity template.

setVlanIdInETH.vm and setVlanIdInLT.vm were exaclty the same.
This patch renames these templates to setVlanId.vm and updates actions accordingly.