Fix AAPP L1b reader not to up-cast data to float64

[pnuu]

The aapp_l1b reader was returning the data as float64. This PR forces the data to float32.

• Closes #xxxx
• Tests added
• Fully documented
• Add your name to AUTHORS.md if not there already

[pnuu]

Memory and CPU usage graph using main:

the same with this PR:

These were done with 12 composites, nearest neighbour resampling and saving to COG.

The memory usage was reduced by approx. 1.4 GB and processing time by 5 seconds.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.05%. Comparing base (084b114) to head (15a0800).
Report is 101 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2893      +/-   ##
==========================================
- Coverage   96.06%   96.05%   -0.02%     
==========================================
  Files         370      370              
  Lines       54320    54334      +14     
==========================================
+ Hits        52185    52191       +6     
- Misses       2135     2143       +8     

Flag	Coverage Δ
behaviourtests	3.99% <0.00%> (-0.01%)	⬇️
unittests	96.15% <100.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[coveralls]

Pull Request Test Coverage Report for Build 10664568987

Details

• 32 of 32 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall first build on bugfix-aapp-l1b-float32 at 96.152%

---

Totals
Change from base Build 10654375136:	96.2%
Covered Lines:	52422
Relevant Lines:	54520

---

💛 - Coveralls

[pnuu]

@mraspaud ok to merge?

[mraspaud]

LGTM

[djhoese]

@pnuu any idea how long this upcasting had been going on? After this PR some integration tests of mine for my Polar2Grid project are showing ~11% of pixels being slightly different. I don't think I'm using numpy 2 yet so does that mean this upcasting has been going on for many years?

[pnuu]

@djhoese float64 seems to originate from here where it was changed from float, so 2 years back.

[pnuu]

And to look further, prior to that the dtype had been float64 for a while when it was changed to it from np.float in 605bc63 . And after checking the changes backwards in time until mpop era, it has always been either float, np.float or np.float64, which I believe all are/were 64-bit.