Specialize target and level arguments that can be statically determined

[EFanZh]

This PR intends to optimize binary size by avoiding passing target and level arguments if they can be determined statically.

I have rewritten the implementation of the log macros to parse each argument separately in order to map macro arguments to the underlying __private_api::log function arguments.

Here is the binary size result tested using https://github.com/EFanZh/log/tree/binary-size-test/cargo-binstall:

opt-level	lto	codegen-units	original size	optimized size	diff
3	off	1	15714240	15714240	0
3	off	16	18257920	18257920	0
3	thin	1	16803704	16791416	-12288
3	thin	16	19269592	19257304	-12288
3	fat	1	15415128	15402840	-12288
3	fat	16	16418616	16398136	-20480
"z"	off	1	11921344	11917248	-4096
"z"	off	16	13867008	13871104	4096
"z"	thin	1	12806008	12801912	-4096
"z"	thin	16	14108632	14104536	-4096
"z"	fat	1	10385240	10381144	-4096
"z"	fat	16	10893144	10889048	-4096

Here is the runtime performance benchmark result tested using https://github.com/EFanZh/log/tree/benchmark.

original  => cycles: 1110, instructions: 70, wall time: 310ns.
optimized => cycles: 1126, instructions: 70, wall time: 280ns.

Note that I have added #[inline(never)] to the log function to prevent the compiler from calling log_impl directly which could affect the optimization. Without #[inline(never)], the binary size change will be:

opt-level	lto	codegen-units	original size	optimized size	diff
3	off	1	15714240	15714240	0
3	off	16	18257920	18257920	0
3	thin	1	16803704	16803704	0
3	thin	16	19269592	19261400	-8192
3	fat	1	15415128	15419224	4096
3	fat	16	16418616	16418616	0
"z"	off	1	11921344	11921344	0
"z"	off	16	13867008	13871104	4096
"z"	thin	1	12806008	12801912	-4096
"z"	thin	16	14108632	14104536	-4096
"z"	fat	1	10385240	10385240	0
"z"	fat	16	10893144	10889048	-4096

Personally, I prefer keeping #[inline(never)], since it has better binary size, and no significant performance cost.

[EFanZh]

Hi @Thomasdezeeuw, this PR is ready for review, would you like to take a look at it?

[Thomasdezeeuw]

I'm not sure this is worth it to be honest. The macros are already complex and this makes it even worse.

I'm also not the biggest fan of the introduced traits. I understand the thinking behind it, but again it adds more complexity.

Looking at the binary size reductions, they're not that great, less than 0.1% in most cases if I'm reading the tables correctly. Furthermore a lot of the size reduction seem to come from adding #[inline(never)]. What are the binary size differences when only adding that?