created Resources trait and associated Resources object.

[VzxPLnHqr]

Mnemonics now work on all platforms. Accessing the wordlist resource file was not working in scoinJS or scoinNative before as far as I can tell. All tests now pass on all platforms.

[VzxPLnHqr]

rebased on #29 (which fixes compilation for scala 2.13.8).

[VzxPLnHqr]

I reworked this to be more inline with the naming of objects and files that we currently have. However, I also wanted to demonstrate how to do it in a slightly more general way without breaking existing code:

• Instead of trait Resources, instead we do trait Resources[F[_]]
• then we provide an implementation on each platform for F = cats.Id (reminder type Id[A] = A)
• the Id instance is then used in MnemonicCode.scala because the rest of the code in that file and all files depending on it are essentially tied (for now) to the Id monad

However, as we refactor things, we can/should consider pulling the functionality offered by the various toplevel objects into their own traits. Using MnemonicCode as an example, it could be rewritten to be:

abstract class MnemonicCode[F[_] : cats.MonadThrow ] {
     // all the methods currently returning a type `A` would be rewritten to return `F[A]`
}

Then an instance for any given Monad can be summoned easily (and/or specialized instances provided too).

Sorry if this is not making a lot of sense yet. Just trying to provide some motivation (but failing to make it clear) that slightly generalizing things in this way gives the end user much more flexibility (while still providing default instances so they can be productive right away).

[VzxPLnHqr]

will re-open and fix if it becomes more of a need/issue