integrating essence of opensim-git 91e1aaa5d41c29fa17609c69ca8bc2a8017dc161 and e0c6bfa81e842f4ba1534882c6d76a3e6e94d68b:

Those patches remove unneccessary data transfers during Sim-Crossings.

Signed-off-by: ft <ft@noemail>
added new git hooks
Revert "integrating essence of opensim-git 91e1aaa5d41c29fa17609c69ca8bc2a8017dc161 and e0c6bfa81e842f4ba1534882c6d76a3e6e94d68b:"

This reverts commit bf81ef111e3289c07c739a772c35782b109e6992.

That patch removes unforeseen parts of the avatar data transfer
added a minor correction to the sit target position
the value is exactly 0.009451
corrected compabilability of those patches merged
reverted b5481a998a1d0343fd22a53c73a009efadb3c445:

the measurement was struck by terrain.
added usability to llSetCameraParams

cryptic exception messages do not help
Merge commit 'upstream/master'
improved usability of error messages within llSetPrimitiveParams and llSetLinkPrimitiveParams(Fast)
integrating opensim-git 3fe9c7c49d9c39ad879c1175c01c8cacced56046:

Fix looking up line number and colum when there is no exact match.

When a compile error reports a colum/error that is not an exact
match in the positionMap dictionary, the last position in the
map with a line number and position before the reported error
should be returned.

The old code had the following problems:
1) It returns l,c - which are line and column of the C# file, not LSL.
2) It doesn't set l to 'line' when the map has an entry with 'line'.
3) It sorts the map without taking columns into account, which may
   result in a random order of the columns. With my mono implementation
   the columns were reversed in order.

For example, if the map contains the following lines:

99,5,49,10
100,30,50,10
100,40,1,0
101,5,51,10

and a translation of 100,35 was requested,
then the old code would compare '100' with the keys in
the first column - setting l to that key while it is
smaller. Hence, l is set to 99.
Then it finds the key 100 and doesn't update l.
Because of the reversed sort order, it first compares
the column 35 with 40, finding that it is smaller
and therefore it stops; returning 99,1 instead of finding
the correct 100,30 entry and returning 50,10.

This patch causes 50,10 to be returned.

The remaining problems after this patch are:
1) The sorting might not be necessary at all.
2) The is code duplication (I fixed both instances,
   but really there should be no code duplication
   imho).

Signed-off-by: ft <ft@noemail>