Fix UB in void* pointer arithmetic and memory leak in VIF init

[StormBytePP]

Fix undefined behavior in void* pointer arithmetic and a potential memory leak in the failure path of vif_init().

Changes

• Replaced all data += N operations (which are UB on void* per C standard) with the portable and well-defined idiom data = (char *)data + N.
• In the fail: label, we now free the original allocation pointer (s->public.buf.data) instead of the advanced data pointer, preventing a memory leak when vmaf_feature_name_dict_from_provided_features() fails.

Why

• The original code relied on a GNU extension (treating void* as char* for arithmetic), which is not guaranteed by the C standard and can break under strict conformance or aggressive optimizers.
• The leak was present even before this change; the UB fix simply made it more visible.

The memory layout and runtime behavior remain identical — only the correctness and portability are improved.

No functional change, only standard corrections.

[kylophone]

Maybe just change the original type instead of casting N times?

[StormBytePP]

Maybe just change the original type instead of casting N times?

I wanted to maintain the original format so the changes introduced are minimal.

Edit: There are some fields which still require explicit casts if original type is changed (at least in mingw) like:

../src/feature/integer_vif.c:636:23: error: assignment to 'uint16_t *' {aka 'short unsigned int *'} from incompatible pointer type 'char *' [-Wincompatible-pointer-types]
  636 |     s->public.buf.mu1 = data; data += h * s->public.buf.stride_16;
      |                       ^
../src/feature/integer_vif.c:637:23: error: assignment to 'uint16_t *' {aka 'short unsigned int *'} from incompatible pointer type 'char *' [-Wincompatible-pointer-types]
  637 |     s->public.buf.mu2 = data; data += h * s->public.buf.stride_16;

So I reverted because I think it is more readable to have all casted uniformly instead of sometimes and sometimes not. What do you think?