Introduced Rendered Service Path

One of the problems with the current code is that the constructed
service path is written in the config data store by merging SFF/SF
information with config provided by the user. This is very bad and I
tried to avoid changing this but it needs to be done if we are serious
about SFC.

The problem is that after SFC provider modifies the SFP with data from
SFF, SF, etc and commit its, it triggers the listener again, which
recreates the path again, which triggers the listeners again, in an
infinite loop. Today I break the loop by using a trick but it makes
the code fragile, specially in the face of modifications, as opposed
to SFP creations.

So, thinking about making the code rock solid, this is what I will be
working on (let me know feedback):

- I will introduce a new yang model called “Rendered Service Path”.
The IETF architecture document actually has this construct. This will
be an    operational yang model. Meaning it can not be changed by the
user.

- When user creates a SFP, provider will include SFF/SF
information and save it in a RSP.  This will not trigger any listener
and information will    be protected from RESTconf.

- Modificationsto SFP by the  user will carry to RSP but not
vice-versa (of course). This makes the code much more reliable and
predictable.   It also makes it easier for the Python agent since
 there is no confusion about what is actually something it needs
 to act on (RSP) versus something
that might not be complete (SFP).

- Changed SF and SFF operational containers. Changed from leaf-list
  to list because it is error prone and tricky to update leaf-lists
  in ODL. It requires reading the list, copying, updating and
  writing it back. In the case of list a single indexe operations
  to add/delete/update is possible.

- Changed SFcProvider*API to use new DataStore APIs. This reduced a lot
  of repetitive code

- Removed dead code



Change-Id: I42cfda4c2a83c0e651523852c3c0dc064dbe7127
Signed-off-by: Reinaldo Penno <rapenno@gmail.com>