1.1 Update - Slight Restructuring + Quality of Life Changes

After the 4.4 update to the Godot engine, I've decided to come back to this addon to restructure it a bit, and as well as add some much needed features that I think will help streamline the use of this addon. This update only works with Godot 4.4, so if you're still using 4.3 or below, I'd suggest that you upgrade to take advantage of this addon.

1.1 Changes:

• Changed path references to UIDs where applicable, with the exception of shader files for the sake of readability. Hovering over a UID in the shader code editor doesn't lead you to its actual path, unlike the regular script editor.
• Changed bone tracking with a new PaperBone2D class, which auto-replaces Bone2Ds. PaperBone2Ds tell the PaperSkeleton node to update the Skeleton3D only when the transform has been updated, instead of needing to check if the transform has changed each frame. 
• PaperBone2Ds display bone modifier properties directly on them instead of in the PaperSkeleton node. Bone modifiers can still be accessed on the PaperSkeleton node by enabling "Show Bone Modifiers". 
• While I'd love to provide a similar setup for Polygon2Ds to no longer necessitate frame-by-frame property checking, with the way that GDScript is set up, I'm afraid that I simply can't implement the setters required to do that. With that being said, I added a new PaperPolygon2D class that auto-replace Polygon2Ds to add some other new features.
• PaperPolygon2Ds display their local material overrides instead of on the PaperSkeleton node, as I've found that scouring through the property list for that to be *very* tedious in practice. Local shader properties can still be accessed on the PaperSkeleton node by enabling "Show Local Shader Properties".
• PaperPolygon2Ds also have two new properties that are stored on them directly.
  • The first is `polygon_to_copy_index_of`, which is used to copy the spacing index of a different PaperPolygon2D. The idea here is that you'd have two elements next to each other that would logically never intersect (think like eyes or eyebrows). Normally, these would be spaced apart from each other despite never intersecting. Using this would make it so that they both could be on the same "layer" in 3D space. This change is now reflected in the demo with the rig's eyes and eyebrows if you'd prefer to see a visual example. Keep in mind, that if these meshes ever *do* intersect, that will naturally result in some z-fighting, so make sure to use this new property appropriately.
  • The second is `polygon_to_copy_group_index_of`. This only really exists for specialized next-pass border implementations. Let's say you wanted to have a border around a head. Originally, you'd need to manually adjust shader parameters to offset the indexes of the nose, hair, or whatever on the head that its own Polygon2D to match it. Using `polygon_to_copy_group_index_of` auto-assigns the index of that PaperPolygon2D to a new `auto_mesh_z_group` shader parameter that can optionally be used as needed for that purpose. 
    • The pseudo-depth next-pass shader has been modified to properly take advantage of this new functionality, and `calculate_mesh_offset_with_index_offset` in `paper_func_spacing.gdshaderinc` has been removed in favor of `calculate_mesh_offset_with_custom_index`, among other small changes.
• On the topic of shader functions, various UV related shader functions have been renamed to use snake casing instead of camel casing. This is primarily because every other shader function was given snake casing, so this is just for the sake of being consistent with naming conventions. If you've made any custom shaders yourself that take advantage of the UV functions in the shader include files (which is rather likely if you've made any custom shaders), then this is technically a breaking change, so sorry about that. You'll probably want to go back in and rename your UV function calls to reflect this if you're getting any errors.
• Removed frame skip. The aforementioned PaperBone2D changes broke it, and honestly it was hardly a practical enough of a feature to be worth trying to maintain anyway.