@rahaman

There are many changes in this branch, so I expect this merge to be a work in progress for now. Here is an overview of the changes I've made:

Major

• I've removed the heat conduction source files from the examples; I was receiving errors about classes being declared multiple times. Plus, linking to the MOOSE modules through the module loader will be easier to maintain in my opinion.
• I have generated a top-level Makefile which does not change based on the example problem being executed.
• The giraffe.mk file is generated at the top level from the configure process. The default example compiled is giraffe/examples/integration_example but can be changed by pointing the GIRAFFE_EXAMPLE variable to the desired location.
• The giraffe.mk file produced is independent of the METHOD variable. This allows a user to specify which version of Giraffe should be compiled at compile time.
• I've modified the CI to configure and build from the Giraffe root.

Minor

• I've generated more recent GiraffeApp, and GiraffeTestApp classes which use a more recent version of the testing harness and object registration, along with an updated main.C to account for passing through the GiraffeTestApp class.

I realize that configuring and building on the top-level might be moving in the opposite direction which you were planning (based on #3), but I think we may be able to make both behaviors work. For example, instead of having multiple executables is it possible to create a shared library in each example directory and link to that library at run-time? I think that keeping as close to the standard MOOSE-app build system as possible will help in maintaining Giraffe.

Remaining tasks:

• Update README to reflect changes in configure/build process
• Add Debug regression test to CI