contrib: discourage g_type_class_add_private() via "checkpatch.pl"

Our GObject structs should be internal API. In which case, we should
embed the private data in the struct themselves (`_priv`) and use the
_NM_GET_PRIVATE() macro. The advantage is better debugability because
following G_TYPE_INSTANCE_GET_PRIVATE() in the debugger is very
cumbersome. Another (less relevant) advantage is better performance.

Thus, warn about uses of g_type_class_add_private() and
G_TYPE_INSTANCE_GET_PRIVATE().

Note that if the struct and is in a header file (which is usually only
necessary when subclassing the type), then the private data should be
an opaque pointer `_priv` instead, and we should use the _NM_GET_PRIVATE_PTR()
macro. In that case, the use of g_type_class_add_private() and
G_TYPE_INSTANCE_GET_PRIVATE() is correct and the warning is false. But
this is only a warning, for the unusual case where we have deep object
hierarchies.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1396

contrib/scripts/checkpatch.pl

@@ -205,6 +205,7 @@ complain ("Avoid g_clear_pointer() and use nm_clear_pointer() (or nm_clear_g_fre
 complain ("Define setting properties with _nm_setting_property_define_direct_*() API") if $line =~ /g_param_spec_/ and $filename =~ /\/libnm-core-impl\/nm-setting/;
 complain ("Use nm_g_array_{index,first,last,index_p}() instead of g_array_index(), as it nm_assert()s for valid element size and out-of-bound access") if $line =~ /\bg_array_index\b/;
 complain ("Use spaces instead of tabs") if $line =~ /\t/;
+complain ("Prefer implementing private pointers via _NM_GET_PRIVATE() or _NM_GET_PRIVATE_PTR() (the latter, if the private data has an opqaue pointer in the header file)") if $line =~ /\b(g_type_class_add_private|G_TYPE_INSTANCE_GET_PRIVATE)\b/;
 
 # Further on we process stuff without comments.
 $_ = $line;