Valgrind output parser with source code

Added Rust and Fortran source function display support. Also, added an Ada test file. Ada is memory safe, it reports no errors with some possible memory leaks.

I said I wouldn't do it. But, I couldn't leave things in such a state. So, I updated the SDD, HLRs, and SLRs to match the new design that uses ctags. In addition, I ditched cpputest in favor of cmocka. I also reorganized the directory structure and makefile to handle a number of unit and integration tests and reduce clutter in the project root directory. The integration tests now test c, c++, and fortran. Due to an issue with the ctags parsing of fortran, vgp cannot provide the function source code for fortran applications.

The github page readme has been updated to reflect all of this.

I refactored the application to use universal-ctags to parse the function from the source file. This expands the number of support source languages significantly. It now supports all the source languages that Valgrind supports.

The Software Design Document, Low Level Requirements Document, and unit tests are now out of date. If I get around to it, I'll update those. I doubt this will happen though.

I added unit test code coverage analysis, complexity analysis, sloc count, and static code analysis using cppcheck to the makefile. In addition, I added all the required tools to the prereqs make target so you can easily install all the tools you need on a relatively current Debian based system.

That will hopefully conclude the testing updates for now. Unless this tool gets some more interest, I'll leave the requested updates open for now.

I added two issues in github requesting new features. 

The first one is to refactor vgp to use universal ctags to parse the source function from the source file. This would simplify the vgp source code and expand the supported source languages significantly.

The second one is to support Valgrind's xml output. This could simplify the parsing a bit. But, more likely it could future proof vgp. It's less likely that Valgrind will change it's xml output formatting.

I added an integration test with a source file that generates a number of memory access errors and memory leaks. Gemini generated the source file used for testing. You can run the integration test along with the unit tests simply by running "make test" command. You will have to manually inspect the vgp.out file in the build directory for the integration test.

At this point, I have about 32 to 40 hours into this project. The majority of the time was spent on the LLR's and unit testing.

There are a couple improvements I can think of off the top of my head. For instance, I could refactor the application to use ctags to parse the function from the original source files. This could add a significant number of addition source languages with relatively little effort. However unless this little project gets some outside interest, I doubt I will get to that. The C/C++ support is sufficient for my needs.

I added some command line flags to control the output of the parser. By default, it will only list the errors reported along with the source file name and line number. If you run vgp in a terminal window in VsCode, you can <Control + Left Mouse Click> on the filename:Line# to navigate to the source line in the appropriate source file. The new command usage is as follows:

Usage: vgp [options] <valgrind_log_file>
Options:
  -v : Enable verbose output
  -s : Print source code
  -l : Print leak summary
  -t : Print stack trace
  -h : Show this help message

Using Gemini 2.5 Pro, I added a fairly complete set of high level requirements, low level requirements, and unit tests. Doing so discovered a couple low priority issues with the internal functions. Most were around parameter checking. Since these are all internal functions, those issues were very unlikely to be a problem. So, I would rate the improved quality due to the unit testing as minimal.

However, the effort highlighted why certified code is difficult and expensive. For the 680 line source file, there are not 3,800 lines of test code. That's ignoring the effort to generate a set of high and low level requirements.