drawWedgeLine does not respect y datum

[MyriadBugs]

https://github.com/Bodmer/TFT_eSPI/blob/caa1076c138c89578bfb4bb2535dbe1faeaa96c7/TFT_eSPI.cpp#L4471C19-L4500C19

The drawWedgeLine function uses clipWindow to.... clip the window and apply the datum/origin offsets. X positioning uses the freshly clipped and shifted x0 stored in xs; however, the y scanning directly uses the ay/by floats which were were not clipped to the window AND didn't have the ydatum applied to them.

1. Create a sprite 100x100
2. Set Origin to 0,-100
3. drawWideLine from 0,80 to 10,120 Instead of the wide line starting off-screen and coming down into the top of the sprite, the line will start at the bottom of the screen and drift off the end.

My quick hack was just the following before we set ys to ay or by. I don't think this will correctly clip the actual thickness of the line but it's good enough for my objectives.

if (!clipWindow(&x0, &y0, &x1, &y1)) return;
//quick hack for datum respect
	ay += _yDatum;
	by += _yDatum;

	// Crop drawing area bounds
	if (ay < _vpY) {ay = _vpY; }
	if (by < _vpY) {by = _vpY; }
//end hack.
  int32_t ys = ay;
  if ((ax - ar) > (bx - br)) ys = by;

[MyriadBugs]

Note, I discovered a related issue, because the datums are already applied, the readPixel within drawWedgeLine call will apply the datum offset an extra time and cause reads from the wrong position (datum * 2). My ugly fast hack was just to subtract the datums within the method call to readPixel.

Also: Small Doc/Feature Request: When I first started using the library I assumed TFT_TRANSPARENT would be 0x00FFFFFF and was the value to pass to bg_color if you wanted to decide at runtime whether to have transparent backgrounds. Took me a while before I realized that it was for a different purpose.

[Bodmer]

Yes, the smooth graphics functions do not play well with the setViewport or setOrigin functions. It is on my TODO list.