Fix for possible unaddressable write.

DrMemory reports unaddressable write of 2 bytes (a single unicode character)
in GetClipboardFormatNameW.

While the API documentation do not imply that the buffer length excludes
the null terminator, the returned length does.
Even though in my case the format name was "HTML Format" which is
far shorter than the 256 character buffer size, DrMemory consistently
cought unaddressable write at the end of the buffer.

It's not clear why GetClipboardFormatNameW would need to access
beyond the length of the data it writes, but this fix is harmless
and at least will silence DrMemory, if not fix a genuine issue.

Change-Id: Ib8ac69a65d4fcff53e71f56f9a06c9c7299be1ba
Reviewed-on: https://gerrit.libreoffice.org/14286
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

dtrans/source/win32/dtobj/DataFmtTransl.cxx

@@ -170,7 +170,7 @@ OUString CDataFormatTranslator::getClipboardFormatName( CLIPFORMAT aClipformat )
 {
     OSL_PRECOND( CF_INVALID != aClipformat, "Invalid clipboard format" );
 
-    sal_Unicode wBuff[ MAX_CLIPFORMAT_NAME ];
+    sal_Unicode wBuff[ MAX_CLIPFORMAT_NAME + 1 ]; // Null terminator isn't counted, apparently.
     sal_Int32   nLen = GetClipboardFormatNameW( aClipformat, reinterpret_cast<LPWSTR>(wBuff), MAX_CLIPFORMAT_NAME );
 
     return OUString( wBuff, nLen );