Remove index_in_caller and index_in_callee from InstructionAccount

[LucasSte]

Problem

In SIMD-0177, we propose sharing the struct InstructionAccount with programs. That struct contains the fields index_in_caller and index_in_callee, which are only used in runtime, not necessary for programs, and are only relevant to ABIv1.

Summary of Changes

1. Create a struct InstructionAccountCallIndexes to hold those two fields.
2. Remove them from struct InstructionAccount.
3. Create a struct InstructionAccountView, which is a a copy of the old InstructionAccount with all the fields, aiming to facilitate field accesses before program execution.
4. Create a struct InstructionAccountViewVector that exposes InstructionAccountViews, but manages internally InstructionAccount and InstructionAccountCallIndexes.

[mergify]

The Firedancer team maintains a line-for-line reimplementation of the
native programs, and until native programs are moved to BPF, those
implementations must exactly match their Agave counterparts.
If this PR represents a change to a native program implementation (not
tests), please include a reviewer from the Firedancer team. And please
keep refactors to a minimum.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 96.77419% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.2%. Comparing base (4cb7c4a) to head (aa32af5).
⚠️ Report is 2887 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff            @@
##           master    #6902    +/-   ##
========================================
  Coverage    83.2%    83.2%            
========================================
  Files         853      853            
  Lines      375383   375444    +61     
========================================
+ Hits       312489   312592   +103     
+ Misses      62894    62852    -42     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Lichtso]

To be honest, it is somewhat over-engineered. There gotta be an easier solution. As you said, one of the fields is never needed again, we could eliminate it. I would rather have more code churn if the result is that we have less distinct structures to maintain afterwards.

[LucasSte]

Superseded by #7220.