Problem:
- Windows version of xnOSGetDirName() returns the directory name followed by a directory separator, which was (seemingly) different from Linux version's behavior. This difference could be a problem when you tried to write a portable code.

Solution:
- Windows version of xnOSGetDirName() now returns the directory name without the directory separator, which should be the same as Linux version.
- Another helper functions, xnOSStripDirSep() and xnOSIsDirSep(), are introduced to implement this in a clean and portable way.

Description of changes:
- XnWin32Files.cpp: Added a code to strip the directory separator in xnOSGetDirName().
- XnOS.h: Utility functions to handle the directory separators are added (xnOSStripDirSep, xnOSIsDirSep)
- XnLibWin32.h, XnOSLinux-x86.h: String constant XN_FILE_DIR_SEPS is added to support both "\" and "/" in Windows. This is helpful for the application programmers to write a portable code by consistently using "/" in any platforms.

Note for Linux: Tested on Windows only.

Fix 1: Drivers' path is now resolved based on OpenNI2.dll's directory.

Problem:
- The drivers' path ("OpenNI2/Drivers" by default) is resolved based on the current directory, which could be a problem because it would restrict the application to be runnable only in a specific directory. See the OpenNI community at http://community.openni.org/openni/topics/search_path_for_redist_files where I originally pointed out this issue.

Solution:
- Now the drivers' path is resolved based on OpenNI2.dll's directory. By default, <OpenNI2.dll's directory>/OpenNI2/Drivers is used. If the custom path is specified by OpenNI.ini (by Repository property in Drivers section), it will be resolved based on OpenNI2.dll's directory if it is relative, or used as it is when it is absolute.
- To specify the custom path, the application can use "/" as the separater even in Windows so that the application can use the same OpenNI.ini regardless of the platform.
- The path resolution by the environment variable (OPENNI2_DRIVERS_PATH) is kept untouched to preserve the current behavior, but I would suggest removing it because it could be no longer useful but might break the consistency between the DLL and the drivers.

Description of changes:
- OniContext.cpp: The drivers' path is resolved based on OpenNI2.dll's directory instead of using the string constant.
- XnOS.h, XnWin32SharedLibrary.cpp, XnLinuxSharedLibs.cpp: Function to get the DLL's path is added (xnOSGetModulePathForProcAddress). See "Note for Linux" also.
- XnOS.h, XnFiles.cpp, XnWin32Files.cpp, XnLinuxFiles.cpp: Utility functions to handle file paths are added (xnOSAppendFilePath, xnOSIsAbsoluteFilePath). See "Note for Linux" also.
- Config/OpenNI.ini: Comment is added to explain how to specify the drivers' path in detail.

Note for Linux:
- This fix has not been compiled or tested on Linux, but intended not to break anything existing at least.
- xnOSGetModulePathForProcAddress() in XnLinuxSharedLibs.cpp needs to be implemented. It should be easily done by using dladdr(). For now, it has the dummy implementation that should not break existing behavior.
- xnOSIsAbsoluteFilePath() in XnLinuxFiles.cpp is implemented but not tested.

Fix 2: OpenNI.ini is now read from OpenNI2.dll's directory.

Problem:
- OpenNI.ini is read from the current directory, which could be a problem by the same reason as Fix 1.

Solution:
- Now OpenNI.ini is read from the same directory as OpenNI2.dll.
- If there is OpenNI.ini in the current directory, it overrides OpenNI.ini in OpenNI2.dll's directory. This feature is kept to preserve the current behavior, but I would suggest removing it because the application's behavior should be independent from the current directory unless the application itself was so designed.

Description of changes:
- OniContext.cpp: OpenNI.ini's path is resolved based on OpenNI2.dll's directory instead of using the string constant.

Fix 3: Improvement of the log configuration timing.

Problem:
- Some logs are not outputted because the log configuration in OpenNI.ini is read too late.

Solution:
- Complete log configuration before any log outputs as long as possible.

Description of changes:
- OniContext.cpp: The order of log configuration and log output was slightly exchanged.

As described in the previous commit, resolving the driver path based on environment variable (OPENNI2_DRIVERS_PATH) and reading OpenNI.ini from the current directory could be only confusing if we started to resolve it based on OpenNI2.dll's directory. If you agree, please use this commit to remove these features. It will make the behavior and the code much simpler and more explainable.

Problem:
- PS1080.ini is read from the current directory, which could be a problem because (1) it would restrict the application to be runnable only in a designated directory and (2) the current directory would be messed up by these driver dependent files. See the OpenNI community at http://community.openni.org/openni/topics/search_path_for_redist_files where I originally pointed out this issue.

Solution:
- Now PS1080.ini is read from the same location as PS1080.dll.

Description of changes:
- XnSensor.cpp:  ResolveGlobalConfigFileName() is modified to resolve the config file's path based on the DLL's directory when the strConfigDir is specified as NULL, and now XnSensor's constructor uses it to initialize m_strGlobalConfigFile.
- XnSensor.h: Comment is added for ResolveGlobalConfigFileName().
- Config/PS1080.ini: Moved to Config/OpenNI2/Drivers/PS1080.ini.

Note:
- Please test the installer (Redist.py) if it deploys PS1080.ini as intended, i.e. along with PS1080.dll.

- OniContext.cpp, XnSensor.cpp: Cast is applied to function pointer to avoid gcc compilation errors. (Thanks to Benn for contribution)
- XnLinuxSharedLibs.cpp: xnOSGetModulePathForProcAddress() is implemented. xnOSLoadLibrary() is also fixed to let dladdr() return the desired information.

…en \0 is passed.