Improved tooltips, sanitized name, and synchronizing 2.8 fixes

[TheDuckCow]

• Adds the poselib.library_name_sanitize operator, which somewhat intelligently takes the active post library name and updates to ensure it appears in the library dropdown (screenshot below)
• Improves tooltips to be more verbose and matching the default user preferences
• Synchronizing some changes from the forked 2.8 repo (https://github.com/jasperges/pose-thumbnails/commit/cedcbdfec7c9ccb88e055ef9c24e5ec528664231)

[TheDuckCow]

@sybrenstuvel I believe I've addressed all your comments, including the function splitting.

Regarding the "rename_for_character", I simplified what I was originally trying to do with regex. Essentially trying to account for these starting names and corrected updated names:

• PLB-CharName-body_poses -> already good, will have nothing to update
• Plb-CharNamebody_poses -> already good, will have nothing to update
• body_poses -> This now updates to PLB-CharNamebody_poses; In the previous commit, I was inserting a hyphen automatically between the charname and the library name, but perhaps it's better to leave that assumption to the user, even if it makes this case less immediately readable?
• CharName-body_poses -> Updates to PLB-CharName-body_poses, as opposed to the simpler logic but less desirable output of PLB-CharNameCharName-body_poses.
• PLB-body_poses -> Updates to PLB-CharName-body_poses, recognizing the prefix was there.
• body_poses-CharName -> I'm not accounting for this mis-setup, so this would still be created as PLB-CharNamebody_poses-CharName which personally I think is fine, the user could correct it understanding the intended pattern.

Let me know if you have any updated thoughts.

[TheDuckCow]

@jasperges not sure if you want to weigh in here at all too, let me know if you have any supplemental comments. Your call of course to consider when to consider this mergeable.

Personal side note on the versioning side of the house (again, just my 2c): I'm sure people have been using this addon, and in blender they see it as v1.0.0; so really, when these changes are in, would it not be appropriate to call it v1.0.1 and then just backdate adding the tag for v1.0.0 to an appropriate spot? I only say that it make it clearer for individuals (... or automated systems, in my own case) to pick up the updated changes.

[jasperges]

@TheDuckCow Sorry, for the late response. I'm swamped with work at the moment. Will look at it as soon as possible.

[jasperges]

@TheDuckCow So I finally made some time to look into this. I will follow your suggestion and do a v1.0.1 release (and add a v1.0.0 tag somewhere at an older commit). Unfortunately I encountered a bug when quickly testing your code (see message above). Do you have time to fix this? Then I will do the release. By the way: in the README I added a link to the wiki (still empty). I will also update the wiki entry in the add-on itself. That way it's easy to add and update documentation.

[TheDuckCow]

Updates made in this pull request: https://github.com/jasperges/pose-thumbnails/pull/53 Sounds good for the wiki, happy to help there that if you're strapped for time.

[jasperges]

I don't mind at all if you make a start with the wiki. My time to work on this will be extremely limited for the foreseeable future. So any help is appreciated. For me it's not a requirement for a new release, though. That's also why I want to use the wiki (other options are also fine with me). I want to have the documentation separate from the source code.

[TheDuckCow]

Agreed - better to have the updated code out and tagged for 1.0.1 than delay for movement in documentation. I'll move the conversation to a doc-issue thread.