boot/bootutil: Split private image API out of image.h

[de-nordic]

image.h will now only contain applicaiton image related structures and defines.
The split has been done to reduce need for including extra headers, for example FIH support and mcuboot_config.h into software that needs the same defining as MCUboot but implements own functions.

[nvlsianpu]

I'm fine with this split

[d3zd3z]

I do like the idea of this split, even though it doesn't really change anything in the code, it at least makes things a little clearer.

I'd really like to see us trying to migrate the APIs in mcuboot to something a bit more modern. I'm thinking of something like how methods work in either Zig or Rust. Where we have clearly defined types, and functions that operate on those types, and not functions that kind of willy-nilly reach between the different types. Ideally, these types would contain the data they need for these methods, for example, a struct that does stuff on a partition, would contain the opened flash api pointer in it (instead of opening and closing every time we use the flash). Each of these structs would have a clear initializer and finalizer as well. Although this has to be done fairly explicitly in C, it is doable (and similar to how it works in Zig).

Getting to this point is a lot of work. But would make it so much easier to play with other ideas we have about supporting newer swap algorithms or newer algorithms for storing the status data.

[de-nordic]

I do like the idea of this split, even though it doesn't really change anything in the code, it at least makes things a little clearer.

I'd really like to see us trying to migrate the APIs in mcuboot to something a bit more modern. I'm thinking of something like how methods work in either Zig or Rust. Where we have clearly defined types, and functions that operate on those types, and not functions that kind of willy-nilly reach between the different types. Ideally, these types would contain the data they need for these methods, for example, a struct that does stuff on a partition, would contain the opened flash api pointer in it (instead of opening and closing every time we use the flash). Each of these structs would have a clear initializer and finalizer as well. Although this has to be done fairly explicitly in C, it is doable (and similar to how it works in Zig).

Getting to this point is a lot of work. But would make it so much easier to play with other ideas we have about supporting newer swap algorithms or newer algorithms for storing the status data.

Yeah, so this PR is part of small cleanups and restructuring of code; as you have stated we should have some rework to improve general structure of code, improve modularity and do some de-coupling.