Throw Error objects instead of strings

Unlike strings, Error objects allow you to get stack traces.
Also, a lot of libraries will complain if they encounter a
thrown non-Error object.

This is in line with standard Javascript best practices.
Per https://eslint.org/docs/rules/no-throw-literal:

> It is considered good practice to only throw the Error
> object itself or an object using the Error object as base
> objects for user-defined exceptions. The fundamental benefit of
> Error objects is that they automatically keep track of where they
> were built and originated.

.eslintrc.js

@@ -178,7 +178,7 @@ module.exports = {
 		"no-tabs": "off",
 		"no-template-curly-in-string": "error",
 		"no-ternary": "off",
-		"no-throw-literal": "off",
+		"no-throw-literal": "error",
 		"no-trailing-spaces": "error",
 		"no-undef-init": "error",
 		"no-undefined": "off",

papaparse.js

@@ -306,7 +306,7 @@
 		}
 
 		// Default (any valid paths should return before this)
-		throw 'exception: Unable to serialize unrecognized input';
+		throw new Error('Unable to serialize unrecognized input');
 
 
 		function unpackConfig()
@@ -1198,7 +1198,7 @@
 
 		// Comment character must be valid
 		if (comments === delim)
-			throw 'Comment character same as delimiter';
+			throw new Error('Comment character same as delimiter');
 		else if (comments === true)
 			comments = '#';
 		else if (typeof comments !== 'string'
@@ -1217,7 +1217,7 @@
 		{
 			// For some reason, in Chrome, this speeds things up (!?)
 			if (typeof input !== 'string')
-				throw 'Input must be a string';
+				throw new Error('Input must be a string');
 
 			// We don't need to compute some of these every time parse() is called,
 			// but having them in a more local scope seems to perform better
@@ -1598,7 +1598,7 @@
 	}
 
 	function notImplemented() {
-		throw 'Not implemented.';
+		throw new Error('Not implemented.');
 	}
 
 	/** Callback when worker thread receives a message */