[ISSUE-783][ISSUE-773][ISSUE-319] Validation Mode and Cleanup

[AndrewBMadison]

Closes #783
Closes #773
Closes #319

Description

This PR replaces and continues work from #794

Continues from work on #794:
CMAKE build types cleaned up in cmakelists

# Build Type Configuration
#
# CMake support for different build types controlling optimization, debugging and profiling:
#
#   - Debug         : No optimizations (`-O0`), includes debug symbols (`-g`).
#   - Release       : Optimized build (`-O3`), removes debug symbols.
#   - RelWithDebInfo: Optimized (`-O2`) but keeps debug symbols (`-g`) for profiling.
#   - Profiling     : Custom build type (defined in this project) that enables:
#                     - CPU profiling via `-pg` (GPROF)
#                     - CUDA profiling via `-lineinfo` (for Nsight Compute)
#
# Selecting a Build Type:
#   - By default, CMake does NOT set a build type for single-config generators.
#   - If no build type is specified, this script defaults to "Release" for performance.
#   - You can explicitly set the build type when configuring CMake:
#
#       cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug      # Debug mode
#       cmake -S . -B build -DCMAKE_BUILD_TYPE=Release    # Release mode
#       cmake -S . -B build -DCMAKE_BUILD_TYPE=Profiling  # Profiling mode 
#       
#       If you don't want to pass in the build type flag, you can edit this file and add...
#               set(CMAKE_BUILD_TYPE "Debug") or whichever build type you want
# -----------------------------------------------------------------------------

Additionally, added a new conditional flag to change the target architecture for cuda compilation.

#CONDITIONAL FLAG to change target architecture for the GPU simulator from the default
#
#You can pass this flag when running cmake from the command line like this, setting TARGET_ARCH \
#       to your desired architecture:                                                            \
#
#cmake -D ENABLE_CUDA=YES -D TARGET_ARCH=70 ..
#
#"YES" / GPU choice only available if CUDA library is installed and the GPU is CUDA capable.
#If no TARGET_ARCH is passed in then it will default to 37 which is the kepler architecture

Quickstart guide, StudentSetup, and codingConventions documentation was updated.
Added support for nvtx profiling tools. The profiling build option will enable this if the nvtx libraries are present.

About the comment in #794 about the build.sh file added to the .gitignore here: I have created a build.sh file with the intention in mind to create a simple build script with machine specific build and compile flags that eliminate the need to retype every conditional flag every time I do a cmake. Others who wish to run graphitti on their own machine can follow similarly, but since it is changed regularly to test different build and compile options it shouldn't be tracked by git. For example in my build.sh:

set -e  # Exit immediately if a command exits with a non-zero status

# You can allow a build type to be specified as an argument; default is 'Release'
BUILD_TYPE="${1:-Release}"



# Print result (for debugging)
echo "BUILD_TYPE: $BUILD_TYPE"

# Where to build (you can customize this directory)
BUILD_DIR="build"

# Clean up previous build artifacts if desired

# Invoke CMake with the desired flags
cmake -S . -B "${BUILD_DIR}" \
  -DENABLE_CUDA=YES \
  -DTARGET_ARCH=75 \
  -DCMAKE_BUILD_TYPE="${BUILD_TYPE}" 
  # Now build. The "--build" command is cross-platform.
cmake --build "${BUILD_DIR}" -- -j$(nproc)

Implements the validation mode outlined in #319
There is a new conditional flag to turn on the validation mode

#CONDITIONAL FLAG to turn on the validation mode
if(NOT VALIDATION_MODE)
        set(VALIDATION_MODE NO)
endif()

When validation mode is enabled, the MTRand on the host generates noise for each vertex every time the simulation advances. This noise is then copied to the randNoise_d buffer for use in the GPU’s advanceVertices kernel. As long as cgraphitti is also run in validation mode, the generated noise will match, ensuring that each vertex receives noise from MTRand in every advanceNeuron call, regardless of whether it is refractory or firing.

Noise is generated in reverse order, from the highest to lowest vertex, because advanceVertices processes neurons in that sequence. While it may be worth investigating whether advanceVertices should instead process vertices in their natural order, the validation mode remains functional after accounting for this behavior.

Validation mode collects and logs data on noise, Vm, summation points, and Inoise during each vertex update, saving the information to vertices.txt in the Debug output folder. However, this process is slow. The next step in validating the GPU and CPU algorithms is to analyze the exported data to identify the cause of slight deviations in simulation results.

Checklist (Mandatory for new features)

• Added Documentation
• Added Unit Tests

Testing (Mandatory for all changes)

• GPU Test: test-medium-connected.xml Passed
• GPU Test: test-large-long.xml Passed