added support for Mygica T230 pids 0xc68a, 0xc69a, 0x689a

[rga-medix]

I have a Mygica PT362 with USB PID 0x689a which should be the latest device of the series.
It requires a different power on GPIO sequence: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/media/usb/dvb-usb-v2/dvbsky.c?h=v5.15.203#n582

Additionally I have noticed that C2, C2_LITE and T230A(this is the PT362) require SI2168_TS_CLK_MANUAL
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/media/usb/dvb-usb-v2/dvbsky.c?h=v5.15.203#n544

Before:
W System.err: info.martinmarinov.drivers.DvbException: Timed out reading from register
W System.err: at info.martinmarinov.drivers.usb.silabs.Si2168.si2168_cmd_execute(Si2168.java:126)
W System.err: at info.martinmarinov.drivers.usb.silabs.Si2168.attach(Si2168.java:153)

After:
D Si2168 : Chip SI2168_CHIP_ID_D60 successfully identified
D Si2168 : Uploading firmware to SI2168_CHIP_ID_D60
D Si2168 : firmware is in the new format
D Si2168 : firmware version: D 6.0.2

This PR

• closes MyGica (Geniatech) T230C DVB-T/T2/C not actually supported? #41
• closes Please add support for Mygica PT362 tuner #54
• closes Help me! Please add support for Mygica PT362 (Type-C) #58

[rga-medix]

I have now additionally tested a C2 product which actually is sold as T230C, so this is the actual product mentoned in #41

idVendor=0572, idProduct=c68a, bcdDevice= 8.00

Since introduction in Kernel with version 5.4 in 2019 up to the latest version for devices with CLK_MANUAL the ts freq was set BEFORE ts mode was set. I have altered the behaviour for the new CLK_MANUAL devices while preserving the previous behavioras I don't have devices to test and confirm.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/media/dvb-frontends/si2168.c?h=v7.0.1#n92

[rga-medix]

while investigating sporadic single timeouts for si2168_cmd_execute(new byte[] {(byte) 0x85}, 1, 1); I have noticed that ts_clock_inv was set in an unusual way. In Kernel it was always 0x00 or 0x10 since 2014.

Here we have both:

si2168_cmd_execute(new byte[] {(byte) 0x14, (byte) 0x00, (byte) 0x09, (byte) 0x10, (byte) 0xe3, (byte) (0x08 | (ts_clock_inv ? 0x00 : 0x10))}, 6, 4);
byte[] cmd = new byte[] {(byte) 0x14, (byte) 0x00, (byte) 0x08, (byte) 0x10, (byte) 0xd7, (byte) 0x05};
cmd[5] |= ts_clock_inv ? 0xd7 : 0xcf;
si2168_cmd_execute(cmd, 6, 4);

My commit follows Kernel logic, but as I assumeolder devices work just fine with it, I also kept the original logic it to not break anything for older devices.