Problem

Fixes #1131

When pixelDensity, get/set operations no longer work on logical but instead physical pixels. This is confusing for users who think that their image is size pixels. This behavior will become particular problematic when fractional scaling is introduced as it's more difficult to reason about that size * 2.

Solution

Ensure that operations are always done in logical pixels, upscaling/downscaling into physical pixels when doing write operations to the backing texture.

Add a new pixel access mode constant that determines whether linear or nearest neighbor sampling should be done when scaling. This isn't super helpful right now but will become more important when fractional scaling is introduced.

To be honest, I'm still not 100% sure this is the right solution. It's clear that the PImage api was always intended to be physical pixels and indeed we now introduce a weird distinction where base PImage will continue to use physical pixels since it doesn't make sense to refer to images as having a scaling factor. It's probably good for users to not have to know about these concepts but also introduces inherent confusion when using high dpi scaling. More robust documentation could probably help here but I'm still a little apprehensive as this is a substantial change (i.e. a totally new contract that we always use logical pixels).

TODO:

• Check whether off screen rendering still works
• Confirm whether we need to do gamma correction when doing software rendering in PGraphicsJava2D
• Test more examples to see if anything broke
• Double check if there's a better existing pattern for the gpu copies when binding the output texture is necessary
• Double check depth writes still work + msaa can be configured