Remove "testing" import from public interface

[abhinav]

Currently, the DoTestCase, DoTestCaseFile, and DoTestCases functions,
are exposed as part of the public interface.

func DoTestCase(m Markdown, testCase MarkdownTestCase, t *testing.T)
func DoTestCaseFile(m Markdown, filename string, t *testing.T)
func DoTestCases(m goldmark.Markdown, cases []MarkdownTestCase, t *testing.T)

Implementing these functions requires importing the testing package.
Importing the testing package automatically registers a number of
global command line flags.

The effect of this is that any application using the standard flag
package with goldmark will automatically get a number of unwanted
command line flags. This is verifiable with the following program,

package main

import (
	"flag"

	_ "github.com/yuin/goldmark"
)

func main() {
	flag.Parse()
}

To fix this, the testing import needs to be removed from all non-test
files. There are two ways to go about it,

• If the functions are meant for external use, you can define an
  interface with a subset of the methods of testing.T and switch the
  functions to consume that. This is what testing libraries like
  gomock and testify do.
• If the functions are meant for internal use, you can remove them from
  the public interface of the library and use them only from tests.

Since these functions are meant to be used by external extensions, I've
introduced a TestingT interface that is a subset of the functionality
provided by testing.T. It supports the standard operations: logging,
skiping, and failing tests,

This also moves those functions into a testutil subpackage. This will help
keep the top-level goldmark package clean and limited to core functionality.

(Note that tests in the top-level goldmark package that make use of
these functions must now use the package name goldmark_test so that
they're considered separate from the main goldmark package, otherwise
you'll see an import cycle: goldmark imports testutil imports goldmark.)

[yuin]

Nice PR.

Hmm, these functions will be used by external extensions, so these functions are not 'internal` functions.

So testutil may be good for just /testutil than /internal/testutil .
Or It is better to take different way like you've suggested?

[abhinav]

Ah, so these are meant to be used externally. I'll move them to /testutil
and add a TestingT interface. That keeps testing APIs out of the main API
and still makes it possible to use the library without importing "testing".
Plus if the testing APIs ever get complicated and need their own tests, a
TestingT interface can have a fake implementation.

[yuin]

LGTM, Thanks!