fix: Refactor Farcaster typing to be explicit

[robpolak]

What changed? Why?

1. Be more explicit on our Farcaster request / response types.
   2. Decided against importing the Farcaster types from @farcaster/hub-nodejs as the object types were more complex and could confuse consumers. Extract + simplify the interface.
2. Added a farcaster message verification integration test.

Notes to reviewers

How has it been tested?

 yarn test
 PASS  src/utils/neynar/user/neynarUserFunctions.test.ts
 PASS  src/core/getFrameValidatedMessage.test.ts
 PASS  src/core/getFrameMetadata.test.ts
 PASS  src/core/getFrameAccountAddress.test.ts

Test Suites: 4 passed, 4 total
Tests:       8 passed, 8 total
Snapshots:   0 total
Time:        1.876 s, estimated 2 s
Ran all test suites.

❯ yarn test:integration         
 PASS  src/utils/neynar/neynar.integ.ts
 PASS  src/core/farcaster.integ.ts

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        2.399 s
Ran all test suites.

[Zizzamia]

Open question should we keep this as getFrameValidatedMessage or have getFrameMessage.
As now we are returing isValid.

[Zizzamia]

Also should is data more correct than message?

[robpolak]

agree and agree .. pr updated

[cnasc]

I think this could be a tagged union, like:

type FrameValidationResponse =
  | { isValid: true, data: FrameData }
  | { isValid: false, data: undefined }

Then if isValid is true the typechecker should know that data is defined and vice-versa

[robpolak]

that is pretty cool

[Zizzamia]

Amazing!!!
I am going to merge and then release a 0.2.0 version at 5pm PST.
With explicit call on this breaking changes.