fix(types): Correctly describe and handle various include option types

[lobsterkatie]

There are three places where this plugin is more permissive in its option types than its underlying @sentry/cli dependency:

• include option: Can be given as a single path (either in string or descriptor object form) here, but must be an array for @sentry/cli

• ignore option: Can be given as a single path (a string) here, but must be an array for @sentry/cli

• ignore option in include descriptor object: Can be given as a single path (a string) here, but must be an array for @sentry/cli

In other words, any of the following would. be fine for this plugin, but none would be okay for @sentry/cli:

const options = {
  include: "This needs to be wrapped in an array",
  ignore: "So does this",
};

const differentOptions = {
  include: { paths: ["This whole object needs to be wrapped in an array"] },
};

const evenMoreOptions = {
  include: [
    {
      paths: ["This overall `include` option is fine"],
      ignore: "But this `ignore` option needs wrapping",
    },
  ],
};

To compensate for this, we normalize the plugin options, fixing each of the problems detailed in the example, before we pass them to @sentry/cli. At least, that's what we're supposed to do. The possible problems and combinations of problems got more complicated when descriptor object include values were introduced in #299, and some of them were overlooked. This should fix that problem, as well as expand the tests to cover all scenarios.

There also is currently a (related) problem with our types, which predates the aforementioned PR. In the types file here, we've been inheriting the include and ignore types from @sentry/cli, even though those types are (theoretically) more permissive here than they are there. This also fixes that problem, redefining those types to include the looser options.

[lobsterkatie]

For the record, and in case it helps in understanding the end result of this change, this is what that previous change should have looked like, vis-à-vis the normalization:

(To me it's easier to understand this diff, which squashes that PR and this one, than to look at just the second half of the change, which is what's here.)