Support for Wide Strings in SOCI for Enhanced Unicode Handling

[bold84]

This pull request adds support for wide strings (wchar_t, std::wstring) to the SOCI database library, improving its interaction with Unicode string types such as SQL Server's NVARCHAR and NTEXT.

Key Changes:

1. Implemented exchange_type_traits and exchange_traits specializations for wide string handling.
2. Updated the ODBC backend to support wide strings, including parameter binding and data retrieval adjustments.
3. Modified buffer management to accommodate the size differences of wide characters.
4. Added comprehensive tests for wide string handling, particularly focusing on SQL Server compatibility.

Notes:

• Focuses on the ODBC backend and C++17 standards, but maintains compatibility with earlier C++ versions.
• Sets a foundation for extending wide string support to other database backends in SOCI.

[bold84]

Converting from UTF-16 to UTF-8 is no problem when retrieving data, because the column data type is known.
When inserting/updating though, it is not so straightforward, as we don't have programmatic knowledge of the column data type in advance.

I'm thinking of adding another argument to "soci::use()" that lets the developer override the data type that's used for the underlying ODBC call.

Another issue is the currently non-existing N'' enclosure for unicode strings for MSSQL in case of soci::use().

Another issue is the stream interface. Currently std::wstring isn't supported and as far as I understand, supporting it would require widening the query to UTF-16 before sending it to the DB.

[vadz]

Thanks! This globally looks good but there are globally 2 issues:

1. The new functionality needs to be documented, notably it should be clearly stated that wstring and wchar_t are only supported in the ODBC backend (and only when using SQL Server?).
2. The use of/checks for C++17 are confusing as it's not clear if it is required for wide char support or if it's just some kind of optimization (in the latter case I'd drop it, it's not worth the extra code complexity).