feat: Add Options for Slug

[pete-murphy]

What does this pull request do?

Fixes #3

This adds Options for configuring generateWithOptions and parseWithOptions.

type Options =
  { replacement :: String           -- used to replace spaces 
  , keepIf :: CodePoint -> Boolean  -- which characters are allowed in the slug
  , lowerCase :: Boolean            -- transform characters to lower-case
  , stripApostrophes :: Boolean     -- remove apostrophes (to avoid unnecessary word-breaks)
  }

The changes are modeled after slugify's options argument:

slugify('some string', {
  replacement: '-',  // replace spaces with replacement character, defaults to `-`
  remove: undefined, // remove characters that match regex, defaults to `undefined`
  lower: false,      // convert to lower case, defaults to `false`
  strict: false,     // strip special characters except replacement, defaults to `false`
  locale: 'vi',      // language code of the locale to use
  trim: true         // trim leading and trailing replacement chars, defaults to `true`
})

replacement appears in Options as well, and lower appears as lowerCase. I think the use case for remove and strict are covered by keepIf (I'd welcome any suggestion for better naming). From what I can tell, strict was introduced to cover a common use case for remove which is to remove all non-alphanumeric characters: https://github.com/simov/slugify/blob/4860d7efd6734af8c716f26cd246aa5b1e503163/slugify.js#L45-L47. In slugify, remove takes a Regex, but from examples I've seen it's usually just for matching on a set of characters, so the full power of Regex seems unnecessary. I think CodePoint -> Boolean works as a corresponding PureScript-y API, and also neatly takes advantage of the HeytingAlgebra instance for functions (so one can do isLatin1 && isAlphaNum etc.)

I didn't do anything related to locale or trim.

Also, the intent is that generate and parse work the same as before these changes, though they're now implemented in terms of the *WithOptions functions.

Where should the reviewer start?

Start with changes to Slug implementations of generate and parse, along with documentation changes in there.

Other Notes:

Does the project documentation need to be updated? Should we introduce a new example, or update any existing examples? Does this PR require any other follow-up tasks?

Yes, and I think all relevant documentation has been updated. Note that a trade-off is the loss of guarantees: one no longer knows much about a value of type Slug other than that it's non-empty.

[pete-murphy]

Oop, forgot to update README etc, I can get to that shortly

[thomashoneyman]

Sorry for the wait, @pete-murphy, and thank you for the contribution!