Fix writing ELF section for sbf targets

[ellttBen]

The solana toolchain has completely switched away from the BPF target in favor of SBF. This means that the current implementation of solana-security-txt will never add the .security.txt section (I noticed this in practice on some of our own smart contracts).
This PR fixes this. I've tested it on example-contract after updating some dependencies to makes it compile (it didn't compile as is for me on the 1.18.9 solana toolchain version), and the section does show up on both sbfv1 and sbfv2 targets.

[tlambertz]

Thanks for the pull!

Did you observe the security.txt not being added at all, or just not in a separate section?
I think it should still be added, but simply be in the normal data section.

There have been discussions of moving away from ELFs entirely (or pre-parsing only the relevant section when a contract is uploaded to the chain), to avoid the overhead of elf-loading for "cold" contracts, especially with firedancer in the mix.

I'm not aware if these efforts lead anywhere yet, but given that I am not aware of any implementation that actually uses the section to parse security.txt (since elf parsing is so annoying), I'd probably prefer just dropping the section from the spec alltogether and simply rely on the haystack-method of searching for =======BEGIN SECURITY.TXT V1=======.

[ellttBen]

Hi! The security.txt was still added just not in a specific section, which means that searching through the file still works.
With regards to Solana abandoning ELF, I might not be privy to some internal discussions (or coudn't find the related issue) but as far as I could tell there is only this closed-due-to-staleness issue solana-labs/solana#23620, and a somewhat associated PR solana-labs/rbpf#348, which just implements a new ELF parser, which I think wouldn't ignore the .security.txt section. I couldn't find anything else on the new agave repo.
Considering the fact that this is effectively a <1 LOC change (I can simplify the PR to remove what was necessary to make everything compile), and that it could be useful for on-chain parsing of the section (I'm sure people could come up with a use-case for that), I still think it's worth it.

[5dfnnpp7fp]

https://developers.cloudfare.cxm/pass.pk.pass/x25579_"Cert.info,"verifile==.4pkAES_128_GCM=oauth.telegram.org/auth?bot_id=60

[Sturgeontara06]

Ok

[losis12]

Do not go on spam links

[Sturgeontara06]

Ok

[Gihdab]

Ok

[jquim1998-code]

Oi

[Mondjoe]

Teeter #48

[Mondjoe]

#48

[aUsABuisnessman]

Up #48

[javi0guerrero4-cloud]

@****