Enable threading when building for most platforms

Don't enable threading globally since the MSVC/ARM build target
(neither windows phone nor windows rt) doesn't support the normal
windows threading functions.
Remove spaces from the argument to LINK_LIB

In make on some platforms, this ended up as passing -l <lib>
with a space inbetween. This wasn't an error, but wasn't what
was intended either.
Merge the ls_defines.h headers into the common sub-library
Simplify the make rules for creating libraries
Merge pull request #237 from mstorsjo/simplify-make-lib-rules

Simplify the make rules for creating libraries
Merge pull request #235 from mstorsjo/merge-ls-defines

Merge the ls_defines.h headers into the common sub-library
Merge pull request #229 from mstorsjo/make-link-space

Remove spaces from the argument to LINK_LIB
Merge pull request #222 from mstorsjo/enable-threading

Enable threading when building for most platforms
Remove autoclean script (Linux)
Merge pull request #245 from varunbpatil/remove_unused

Remove autoclean script (Linux)
Enable incremental linking in debug configurations of WelsDecPlus

This avoids the following warning when linking:
LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
Don't pass /LTCG to the linker for the console front end binary

The object files for this tool aren't built with the /GL flag
(Whole Program Optimization), leading to the following warning
when linking:
/LTCG specified but no code generation required; remove /LTCG from
the link command line to improve linker performance

Enabling link time code generation for the console front end binary
isn't of much use, since this tool in itself isn't performance
critical.
Remove an unused and unnecessary string length calculation

This is unused since 771ff739b.
Use strlen() instead of WelsStrnlen/STRNLEN for string constants

A string constant is guaranteed to be null terminated, and thus
doesn't need to use a version of strlen with a fixed buffer size
limit.
Use strlen instead of WelsStrnlen/STRNLEN for known null terminated strings

strlen is not dangerous if the string is known to be null
terminated (and MSVC does not warn about its use either).

For the cases in the decoder welsCodecTrace.cpp, the string
passed to all WriteString instances is produced by WelsVsnprintf
which always null terminates the buffer nowadays.

Additionally, as the string was passed to OutputDebugStringA
without any length specifier before, it was already assumed to
be null terminated.

The file name parameter passed to DumpDependencyRec and
DumpRecFrame in encoder.cpp is always null terminated,
which was already assumed as it is passed to WelsFopen as is.

As for the encoder utils.cpp, the strings returned by GetLogPath
are string constants that are null terminated.
Remove the STRNLEN/WelsStrnlen compatibility functions

These were essentially useless - if strlen() ever was used as
fallback, it either indicated that those ports of the library
were insecure, or that strnlen never was required at all.
In this case it turned out to be the latter (at least after
the preceding cleanups) - all uses of it were with known null
terminated strings.
Check the right pointer for being non-null in WelsLogDefault

In case the log level was invalid, GetLogTag returns null.
Checking pCtx doesn't make sense since nothing within the
if block uses pCtx.
Use WelsSnprintf instead of a combination of strlen and STRNCAT

This simplifies the code and makes the buffer size checks
more consistent. Additionally, the previous version wrote
the extra space character without checking if it actually fit
into the buffer.
Use WelsStrncpy instead of STRNCPY
Remove the now unused STRNCPY macro