Bugfix for COM Record instance creation.

[geppi]

There is a serious bug in the code that creates a new COM Record instance.

It kicks in when a tuple of com_record instances is created from a SAFEARRAY of COM Records.
The bug causes the data of all com_record tuple elements to be stored in the same RecordBuffer segment, i.e. the segment dedicated to the first com_record tuple element.

I'm sorry, this was my mistake in the implementation of PR #2437 and will be fixed by this PR.

[geppi]

Something seems to be broken with the CI workflow:

======================================================================
ERROR: test_creddelete (test_win32cred.TestCredFunctions.test_creddelete)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\pywin32\pywin32\win32\test\test_win32cred.py", line 44, in test_creddelete
    self.assertFalse(self.is_dummy_cred())
                     ^^^^^^^^^^^^^^^^^^^^
  File "D:\a\pywin32\pywin32\win32\test\test_win32cred.py", line 33, in is_dummy_cred
    for e in win32cred.CredEnumerate()
             ^^^^^^^^^^^^^^^^^^^^^^^^^
pywintypes.error: (1168, 'CredEnumerate', 'Element not found.')

[geppi]

It is very important to merge this before the next release, please.
The bug can cause data corruption that might stay unrecognised and lead to surprises because currently:

> a: tuple[RECORD_T, ...] = some_COM_method_that_returns_a_SAFEARRAY_of_RECORD_T_instances()
> a[0].attribute == a[1].attribute
  True

> a[0] is a[1]
  False

> a[0].attribute == other_value
  False

> a[0].attribute = other_value
> a[0].attribute == a[1].attribute
  True

Ooops.

[mhammond]

thanks! It would be great to get a test in a later PR if possible