"calculate" machinery (i.e., declaration functions and instructions)

[paciorek]

Here is the general roadmap discussed 2026-05-13:

• move this repo to nimble-dev. Copy this issue if issues/PRs are not brought over.
• bring Perry's nimbleModel code from nCompiler into nimbleModel repo
• use flattened instrClass, bringing together Chris' uncompiled implementation and nClass implementation with Perry's implementation
  • include declaration ID so outer calculate knows that declClass to use
• in R generate declaration IDs and lock into C++ in some fashion
• bring together both approaches to declClass and its calculate
• bring together both approaches to "middle"/iterator calculate layer ("calcOneInstr" in Chris' terminology) code, namely the code that does the iteration to call calc_one and the like
  • eventually may handle different types of via class system; for now might just use switch
• update uncompiled model calculate to properly handle having multiple instructions, calling into declarations
• bring nCompiler model class together with uncompiled nimbleModel one, having modelDef and the like in Rpublic
• think about how calculation type is determined in creating the instrClass object; who/where controls if vec/parallel is used (assuming it is feasible)
• eventually add calc_vec and calc_parallel; perhaps mainly prototype calc_vec now; consider under what conditions on the declaration to add this and whether it might exist even if not legit to use
• decide on naming - instrClass? declInstrClass, calcInstrClass?
• remove nimbleModel-related code from nCompiler.

In case useful, here are the layers (of 'calculate' but this will hold more generally):

1. model calculate (iterates through nList of instrClass objects)
2. declaration calculate ('decides' which iterator to call based on type in instr object); for efficiency, we don't want much logic/control flow in here
3. middle/iterator calculate (iterates and calls calc_one, calc_vec)
4. primitive/atomic: calc_one, calc_vec, calc_parallel

General plan is for Chris to work on most of this but some C++-side stuff might fall on Perry - perhaps some of the middle/iterator implementation.