Provide an additional friendly overload with raw unconvertible handles when necessary

[DoctorKrolic]

Previously if friendly overload accepted a handle with a known release method CsWin32 would always "promote" it to a SafeHandle. This works well if CsWin32 can trivially represent that handle as a SafeHandle so that function that opens/creates the handle in the first place returns it a a custom generated SafeHandle. However, if release method is a complicated one and CsWin32 cannot generate a trivial SafeHandle wrapper based on it user was forced to declare such safe handle type on their own to use it in other friendly overloads. This might not be ideal e.g. if the handle is used whithin one method frame so that declaring a safe handle type for it is an overkill. Now CsWin32 generates another overload with such handles represented as "raw" handles so that user has a choice either to use the raw handle or to declare their own safe handle type and use it instead

[jevansaks]

There is already a safeHandles knob in NativeMethods.json. How is this different than letting the consumer choose a different form of the projection? More overloads can just be more confusing.

It sounds like from the description this is limited to "complex" handles, could you give some concrete examples for those and how this would help?