The gamma values for some of the PixelFormats seem wrong

### Summary

I believe that some portion of the `System.Windows.Media.PixelFormats` are not correctly described.

### Why I opened an issue instead of a PR

I can demonstrate with some piece of working code that there is some inconsistency in the doc,
but due to the lack of deep understanding I can be only sure about a subset of the dubious part,
so I opened this issue to ask for help instead of opening a PR.

### Demo setup

For the demo, I wrote a simple `ShaderEffect` that takes a 1-D texture as input and renders the grayscale intensity of each pixel as a waveform.
The 1-D texture is filled with a linear gradient from black to white, so when the gamma value is 1.0, the output image should be a linear ramp connecting the bottom-left corner and the top-right corner of the window.

I performed a small set of experiments on this demo program while changing the content of the 1-D texture.

### Experiment 1

I associated with the 1-D texture a `WriteableBitmap` initialized with `PixelFormats.Gray16` and observed a linear ramp, which means the gamma value of the texture was probably 1.0.

Then I associated another one initialized with `PixelFormats.Gray32Float` and observed what looks like an sRGB gamma ramp.
This suggests that the gamma value of `PixelFormats.Gray32Float` is not actually 1.0, contrary to what is described in the doc.

### Experiment 2

I performed the same experiment with `PixelFormats.Rgba64` and `PixelFormats.Rgba128Float`, observing the gamma ramp of all the 4 color channels respectively.

The red, green and blue channels resulted in what looks like an sRGB gamma ramp just like
what I got from `PixelFormats.Gray32Float` in both pixel formats, while I got a linear ramp for the alpha channel in both pixel formats.

This result suggests two things:

1. In both experiment 1 and 2, non-linear gamma ramps were correctly displayed as being non-linear and vice versa, because usually the gamma ramp is only applied to RGB channels and not alpha.
2. Neither `PixelFormats.Rgba64` nor `PixelFormats.Rgba128Float` have a gamma value of 1.0 contrary to what is described in the doc.

### The part I am not certain about

I conducted two simple experiments whose results strongly suggest errors in the doc, but I am not completely certain about this.

I used `ShaderEffect` for the experiments and I did not test any other means of image output, so it could be a bug in the texture transfer from CPU memory to VRAM or something and the gamma values are correctly reflected when GPU (i.e. DirectX) is not involved, in which case it is the internal code of WPF that needs a bugfix, not the doc.

However, I found an [MSDN forum post from 2009](https://social.msdn.microsoft.com/Forums/vstudio/en-US/b1ff3281-7bf7-4fdd-99f3-cdfe286268b1/gray32float?forum=wpf) which describes a similar inconsistency.

The author states that _only the float formats have a gamma value of 1.0 and others do not_ which is not consistent with what I got.
Nevertheless it does suggest that there is some inconsistency.

### Conclusion

I believe the two experiments only point to a part of the problem.

For example, `PixelFormats.Rgb48` is simultaneously described as being an sRGB format and having a gamma value of 1.0.
It does not make much sense because usually, as the MSDN Forum post above suggests, sRGB color space is associated with a gamma value of 2.2.

It seems to me that the entire entry is half-baked, unless I am misunderstanding things at a very fundamental level.
I would be very glad if somebody who knows the WPF internals could review this and provide us with the correct information about `PixelFormats`.

I am willing to publish the code I used for the demonstration if asked. I did not do so in advance because there might be a better and more simple way already.

Thank you in advance.