new feature for change data - PI + folder restructure

[ChaseMillers]

Added a new script and made sub folder for the change table files to keep with proper folder structure.
So 4 changes total if you count moving the other two files.

Overview

This script analyzes the quality of change request data in ServiceNow to determine readiness for Predictive Intelligence (PI) model training. It provides detailed statistics and quality metrics to help ServiceNow developers and admins identify and address data issues before starting ML training jobs.
A

Purpose

• Assess completeness and quality of key fields in change request records
• Identify common data issues that could impact PI model performance
• Provide actionable insights for improving training data

Features

• Checks completeness of important fields (e.g., short_description, description, category, risk, assignment_group, implementation_plan, test_plan, backout_plan, close_notes)
• Analyzes text quality for description, implementation/test/backout plans, and close notes
• Evaluates category diversity and closure times
• Calculates an overall data quality score
• Outputs results to the ServiceNow system logs
  Test:

Overview

• Put an x inside of the square brackets to check each item.
• I have read and understood the CONTRIBUTING.md guidelines
• My pull request has a descriptive title that accurately reflects the changes and the description has been filled in above.
• I've included only files relevant to the changes described in the PR title and description
• I've created a new branch in my forked repository for this contribution

Code Quality

• My code is relevant to ServiceNow developers
• My code snippets expand meaningfully on official ServiceNow documentation (if applicable)
• I've disclosed use of ES2021 features (if applicable)
• I've tested my code snippets in a ServiceNow environment (where possible)

Repository Structure Compliance

• I've placed my code snippet(s) in one of the required top-level categories:
  • Core ServiceNow APIs/
  • Server-Side Components/
  • Client-Side Components/
  • Modern Development/
  • Integration/
  • Specialized Areas/
• I've used appropriate sub-categories within the top-level categories
• Each code snippet has its own folder with a descriptive name

Documentation

• I've included a README.md file for each code snippet
• The README.md includes:
  • Description of the code snippet functionality
  • Usage instructions or examples
  • Any prerequisites or dependencies
  • (Optional) Screenshots or diagrams if helpful

Restrictions

• My PR does not include XML exports of ServiceNow records
• My PR does not contain sensitive information (passwords, API keys, tokens)
• My PR does not include changes that fall outside the described scope

[mskoddow]

Many thanks for that awesome contribution which adds real value to the repository!

I'm just wondering why parts of your code have to be so complicated.

To help you learn, I have added some code snippets that can make your life much easier:

//get all ancestors of a child table
gs.info(SNC.TableEditor.getTableAncestors('incident'));

var grIncident = new GlideRecord('incident');

grIncident.initialize()

//check if a field exists - even in parent tables
gs.info(grIncident.isValidField('number'));

//list all fields in child table including parent fields
var listElements = grIncident.getElements();

for (var numIndex = 0; numIndex < listElements.size(); numIndex++) {
	var objElement = listElements.get(numIndex);

	gs.info(objElement.getName());
}