refactor: remove account dependencies

[highskore]

solves #158 to make #160 work

[highskore]

@kopy-kat a few issues:

• Registry dependency is ^0.8.24
• Seems like memory allocation for < 0.8.26 is not the best so SIMULATE=true doens't work on CI (works locally tho)

[kopy-kat]

Should we remove registry dep too?

[highskore]

Should we remove registry dep too?

done but the 7702 compatibility change added to 7579 ref requries ^0.8.24 for tstore too (we can precompile this tho), but the 4337 repo is ^0.8.23 too

maybe lets just keep it >=0.8.24 <0.9.0 ?

[kopy-kat]

Yeah that’s mid, maybe we remove the 7579 impl too - but yeah maybe we need to stay higher than 0.8.24

[highskore]

Yeah that’s mid, maybe we remove the 7579 impl too - but yeah maybe we need to stay higher than 0.8.24

7579 ref is removed, bumped solc to 0.8.24 >=

All in all this pr removes the kernel, safe7579, 7579ref and registry dependecies

[kopy-kat]

I'm kind of having doubts over essentially scrapping dependencies and needing to manually port over changes. These should be rare tho so it might be fine - wdyt @highskore

[highskore]

I'm kind of having doubts over essentially scrapping dependencies and needing to manually port over changes. These should be rare tho so it might be fine - wdyt @highskore

I think it's fine since it's audited contracts which should in theory only update rarely and the porting is not that bad (just updating bytecode most of the time)

[highskore]

Let's merge #162 first, will probably need to resolve some conflicts @kopy-kat

[highskore]

@kopy-kat Found a nested dependency to erc7579 inside module-bases, do we remove the dependency? We would need to duplicate some code, it's stopping modulekit for being able to use solc 0.8.23 because of the tstore inside latest erc7579 ref.

If not - We could bring back the erc7579 dep here or just merge so I can resolve the conflicts on the downgrade-solc branch and close the PRs

[kopy-kat]

I think this looks good to me - I think we should release it as a new major version

before merging could you try using this branch in core-modules and seeing if anything breaks?