Sort Qual execs report by sqlId and nodeId

[amahussein]

Fixes #1435

This pull request is to make the execs report sorted by SqlID and nodeID.
Overall, it is more readable and easier to troubleshoot the file by looking at the rows grouped by the SQLID next to each other.
Also, this implementation is more optimized because it avoids creating a list of tuples for each row. Instead, it create a string sequence from the execInfo and convert it to string.

This pull request includes several changes to the QualOutputWriter class and related methods to simplify and improve the code for writing execution reports. The most important changes include removing redundant methods, simplifying method signatures, and refactoring the logic for constructing CSV rows.

Simplification and refactoring:

• core/src/main/scala/com/nvidia/spark/rapids/tool/qualification/QualOutputWriter.scala: Removed the constructExecInfoBuffer and constructExecsInfo methods, and refactored the logic for constructing CSV rows directly within the writeExecReport method. This change simplifies the code by eliminating unnecessary intermediate methods. [1] [2]
• core/src/main/scala/com/nvidia/spark/rapids/tool/qualification/QualOutputWriter.scala: Simplified the writeExecReport method signature by removing the order parameter and updating the method implementation to directly construct and write CSV rows.

Method signature updates:

• core/src/main/scala/com/nvidia/spark/rapids/tool/qualification/Qualification.scala: Updated the call to writeExecReport in the Qualification class to match the new method signature without the order parameter.

[nartal1]

LGTM. Thanks @amahussein !

[parthosa]

Thanks @amahussein. A minor question.

[parthosa]

Question: Why do we require the booleanTrue and booleanFalse variables instead of directly using info.shouldRemove.toString?

[amahussein]

Good question @parthosa !
I assume that info.shouldRemove.toString is going to create a new thread each time it is called. We can actually test that by checking the address of the string returned from the call in case Scala is optimized to return a string from an internal pool.
Using the booleanTrue allocates the object only once and shares it with all other records.

[amahussein]

Thanks @parthosa and @nartal1

[amahussein]

Good question @parthosa !
I assume that info.shouldRemove.toString is going to create a new thread each time it is called. We can actually test that by checking the address of the string returned from the call in case Scala is optimized to return a string from an internal pool.
Using the booleanTrue allocates the object only once and shares it with all other records.