The `delegatable`-specific behavior in eip712-codegen

[xinbenlv]

IIRC, this repo and npm package was originally part of delegatable, it turns out, it carries behavior specific for delegatable which was not very obvious and could be confusing to people who try to use this tool for a general purpose.

As of v6.0.8(permlink) it seems such behaviors still exist and I think they need to be generalized.

1. Some structs that are not referenced in the entryPoint are still being generated, while not all. For example, when using the following script to generate

git clone git@github.com:danfinlay/eip712-codegen.git
cd eip712-codegen
git checkout 73b411e83250755c2a1bd068d9f5eaf7b42be039
npm run build
node cli.js --input sampleTypes.js --entryPoints ReplayProtection

• Expected behavior: the output shall only contains struct relevant to the entryPoints and if the struct specified in parameter --entryPoints doesn't reference traversally to another struct, that struct shall not be included in the output sol file. For example when entryPoints is ReplayProtection and it doens't reference directly or indirectly the Invocation or Caveat, those two structs shall not be included in output.
• Actual behavior: the output contains other non-referenced structs, as demonstrated in https://gist.github.com/xinbenlv/55fe92093f53964233891bc19067a21e#file-oldreplayprotection-sol

2. Some generated solidity struct and typeHash and functions seems only useful in Delegatable context, such as SignedReplayProtection because of how Delegatable passes the type with siganture.

Maybe it makes sense that we define some more general behavior and update the eip712-codegen for such goal