Linux kernel ticks assumption is error prone

### Problem
The value of clock ticks (`_SC_CLK_TCK`) is hard coded and might varies across kernel versions and hardware platforms, it would probably be best if you could read this value dynamically.
https://github.com/elastic/go-sysinfo/blob/bd131ab8b5efa45cd7e434c4b14412a253601e07/providers/linux/process_linux.go#L33

There is an assumption here for certain conditions that might not be respected between different deployments and versions.
please read the [wiki article](https://elinux.org/Kernel_Timer_Systems) about Kernel Timer Systems:

> The original kernel timer system (called the "timer wheel) was based on incrementing a kernel-internal value (jiffies) every timer interrupt. The timer interrupt becomes the default scheduling quantum, and all other timers are based on jiffies. The timer interrupt rate (and jiffy increment rate) is defined by a compile-time constant called HZ. Different platforms use different values for HZ. Historically, the kernel used 100 as the value for HZ, yielding a jiffy interval of 10 ms. With 2.4, the HZ value for i386 was changed to 1000, yielding a jiffy interval of 1 ms. Recently (2.6.13) the kernel changed HZ for i386 to 250. (1000 was deemed too high).

### Proposed solution
Make a sys call to retrieve the actual `_SC_CLK_TCK` and use it for process time calculations, the same has been done for Darwin:
https://github.com/elastic/go-sysinfo/blob/f2015f14dd215ad97bd4fbe048e087945ec0223d/providers/darwin/syscall_darwin.go#L191-L194

Read providers/linux/process_linux.go at line 33 and compare the referenced Darwin implementation in providers/darwin/syscall_darwin.go around lines 191-194. Done means Linux process-time calculations use the runtime _SC_CLK_TCK value rather than a hard-coded assumption.

Written by the indexing model from the issue text.