Bump libwally-core to 0.8.5

[Sjors]

For some reason I can no longer build for the device or simulator on macOS 12.3.1:

Undefined symbols for architecture x86_64:
  "_secp256k1_nonce_function_default", referenced from:
      _wally_internal_ec_nonce_fn in libwallycore.a(libwallycore_la-internal.o)
...

[Sjors]

Building the latest master branch from scratch still works for me. My guess is that something in ElementsProject/libwally-core#321 requires updating our build stuff.

@jurvis any thoughts for what would be a quick fix? Or is it better to bite the bullet and make a more rigorous improvement like #61? Update: after review, I think PR 61 should be easy enough to merge so we don't need a quick fix.

[jurvis]

hey @Sjors, I ran to the same issue as well. I believe ElementsProject/libwally-core#321 excludes the secp256k1 symbols so we'll have to manually include the libsecp256k1 static library in our Libwally project.

This is represented by this pbxproj change in #61

EDIT: showing my work:

excludes the secp256k1 symbols so we'll have to manually include the libsecp256k1 static library in our Libwally project.

if you run nm libwallycore.a you'll get this output. where you can see that the symbols are undefined

[jurvis]

TL;DR: #61 should hopefully fix a libwally-core build issue with libtool@2.4.7, support M1 macs running arm64 simulator targets, support xcframeworks for potential Swift Package Manager integration in the future

@Sjors the improvement I'm working on in #61 hopefully achieves a couple of things, actually:

1. Update to libwally-core@0.8.5 which fixes build issues for me with libtool@2.4.7
2. Support running Libwally on M1 Mac running arm64 simulators. This necessitates the use of xcframeworks afaik. lipo will end up packaging both simulator and device arm64 targets which Xcode will not like 😬
3. With that said, 1 enables us to actually clean up our podspec file, and may even mean we can delete the Carthage build script -- since we're actually building the .xcframework directly for users to drag into their project.

At this current moment, if you checkout 60ed50a, run ./build-libwally.sh -sdc, and drag Libwally.xcframework into any iOS project, it builds!

However, I'm having a hard time trying to debug getting it to work with Cocoapods (sample project):

and Carthage currently spits out a bunch of errors for me.

[Sjors]

we'll have to manually include the libsecp256k1 static library in our Libwally project

That was easy enough and did the trick!