Correct the behavior when field xpath is defined with a string function

[moophat]

Sample xml

<bgp-peer style="detail">
    <peer-address>10.2.254.1+179</peer-address>
    <peer-as>7552</peer-as>
    <local-address>10.2.255.3+60079</local-address>
    <local-as>7552</local-as>
    <peer-group>AGG_TO_SRT_TRAI</peer-group>
    <peer-cfg-rti>master</peer-cfg-rti>
    <peer-fwd-rti>master</peer-fwd-rti>
    <peer-type>Internal</peer-type>
    <route-reflector-client/>
    <peer-state>Established</peer-state>
    <peer-flags>Sync</peer-flags>
    <last-state>OpenConfirm</last-state>
    <last-event>RecvKeepAlive</last-event>
    <last-error>None</last-error>
</bgp-peer>

Normally user only specify xpath in the View definition, i.e:
bgp-peer: //bgp-peer/peer-id

Or use a string function as a condition for the xpath
//bgp-peer[starts-with(peer-state,'Essst')]

In these case lxml.etree return a list of lxml.etree._Element object, which work fine with the current view code.

However if we need to perform string manipulation, for example to extract IP from peer-address
substring-before(//bgp-peer/peer-address, "+"), it will return a lxml.etree._ElementUnicodeResult object.
This will be converted wrongly by the next interation (i.e address "1.1.1.1" will be iterated into a list)
We should return the original UnicodeResult.

The fix for this case is simple but I have not look further into other type of return from xml.xpath call, it'll be greate if anyone call look at that and cover all of other possible return.

[coveralls]

Coverage decreased (-0.02%) to 94.98% when pulling 2bda1b1 on moophat:xpath-string-function into 500939b on Juniper:master.

[jnpr-community-netdev]

Can one of the admins verify this patch?