Resolve the path for the drivers and OpenNI.ini based on OpenNI2.dll's directory

Fix #1: Drivers are now seached based on OpenNI2.dll's directory.

Problem: The drivers' path ("OpenNI2/Drivers" by default) is decided 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 problem.

Solution:
- Now the drivers' path is decided 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.
- I left the path resolution by the environment variable (OPENNI2_DRIVERS_PATH) 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: Utilify functions to handle file paths are added (xnOSAppendFilePath, xnOSIsAbsoluteFilePath). See "Note for Linux" also.
- Config/OpenNI.ini: How to specify the drivers' path is explained 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 things.
- 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. I kept this feature 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, if possible.

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