Add islessgreater() term entry for C++ math-functions

[ylevental]

Added documentation for the islessgreater() function including:

• Description of the comparison behavior without floating-point exceptions
• Syntax and parameters
• Examples showing basic usage with different values
• Codebyte example with various data types and edge cases including NaN

Description

This PR adds a new term entry for the islessgreater() function under C++ math-functions as requested in issue #7996. The documentation provides a comprehensive overview of this function, which determines whether a value is less than or greater than another without raising FE_INVALID exceptions. The entry includes detailed explanations of how this function safely handles NaN values, along with practical examples demonstrating its usage with different floating-point types.

Issue Solved

Closes #7996

Type of Change

• Adding a new entry

Checklist

• All writings are my own.
• My entry follows the Codecademy Docs style guide.
• My changes generate no new warnings.
• I have performed a self-review of my own writing and code.
• I have checked my entry and corrected any misspellings.
• I have made corresponding changes to the documentation if needed.
• I have confirmed my changes are not being pushed from my forked main branch.
• I have confirmed that I'm pushing from a new branch named after the changes I'm making.
• I have linked any issues that are relevant to this PR in the Issues Solved section.

[mamtawardhani]

Hey @ylevental, I've requested some changes

[mamtawardhani]

Add a Bold heading Return value:

[ylevental]

Hi @mamtawardhani,

Thank you for taking the time to review this PR and provide detailed feedback. I've attempted to implement all three of your requested changes:

1. ✅ Added Return value: heading
2. ✅ Updated the return value description to be more detailed
3. ✅ Changed output code block to use shell syntax

I also added a Parameters: heading to match the formatting style used in similar entries like isgreater.md, which required restructuring the file.

However, I found the process of trying to address the line-specific feedback while maintaining CI compliance to be quite challenging. The line numbers shifted as I restructured the file to match the repo's formatting standards, and the review comments weren't automatically marked as outdated, which made it difficult to track what still needed to be addressed.

For future contributions, I think it would be more efficient if reviewers could either:

• Make direct edits for formatting/style issues, or
• Provide feedback focused on the content rather than specific line numbers

I'm going to close this PR for now as I'd like to focus on other issues. I appreciate your time and feedback, and I hope this experience helps improve the review process for future contributors.

Thank you!