Fixed the XPath built-in position function for bug #497017

Fixed the XPath built-in position function for bug #497017

According to http://www.w3.org/TR/xpath#predicates, a predicate [n] should be equivalent to [position()=n] for a number expression n. However, we currently have a PredicateIterator intepretation of [n] that has been corrected for the issue outlined in the bug report, leaving the position() function behind with an inappropriate, document-order value for reverse axes. Note that [n] is not treated by parsing or transforming to the same form as [position()=n] before evaluation, valid as that would be.

The discussion in that same section of the recommendation about forward and reverse axes and further remarks in http://www.w3.org/TR/xpath#node-sets make it clear that the predicate [1] has the sense of "nearest" rather than "first in the document" which then, depending on the axis type, may be the same or reverse of the document order. It does not seem to me to be so clear whether the order given by a navigator for a location path expression should mirror this or always give the document order. The .Net implementation seems to always give the document order, as well as predicates having the correct reverse/forward senses, so I have added test cases that explore both.