docs: clean up types and add API docs site

[erickzhao]

This PR adds typedoc API documentation from our TypeScript types for the @electron/osx-sign package.

The module already had some pretty good API documentation available on the README.md, so the PR mostly moves the existing explanations around. This has the added bonus of providing better editor intellisense.

Goals:

• Move API documentation from README.md to code.
• Convert README.md examples from focusing on the legacy CLI to focusing on the JS API.
• Leverage TSDoc directives whenever possible for better TypeScript intellisense experience.
• Add missing information from the GitHub wiki into README.md (Closes Expand wiki #10)

Notes:

• Our internal types are a bit messy, and typedoc works a lot better with TypeScript interfaces rather than types. For example, Omit<A, B> will not be expanded into its underlying properties and will show up as-is by default in typedoc.
• To remedy the above problem, the @interface directive was added to a few types, and the core SignOptions and FlatOptions types were re-exported as interfaces that extends the underlying types.
• This has the nice effect of hiding the mess of utility types for each set of options and makes the docs a lot more useable.

Preview from my fork of this repo: https://erickzhao.github.io/osx-sign/

[erickzhao]

@internal is a typedoc-specific directive used to hide this type from the generated documentation interface.

This is applied to most types in this file since end users don't need to know the implementation details of how we generate SignOptions and FlatOptions.

[erickzhao]

If we prefer keeping this exported as a type, we can instead tag _SignOptions as an @interface.

The tradeoff here is that TypeDoc doesn't detect @interface properly for function signatures, so the doc output for signAsync() will not expand the parameters properly.

[georgexu99]

I'm in favor of exporting it as an interface if it means signAsync() will have correct params

[erickzhao]

Note that this PR doesn't actually set up any publishing for the website. I figured that could go into a follow-up PR where we set a GH Action similar to how electron/packager does it.

[georgexu99]

I'm in favor of exporting it as an interface if it means signAsync() will have correct params

[continuous-auth]

🎉 This PR is included in version 1.3.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀