fix: convert AdditionalMessage param into string type CustomMessage

[freelerobot]

Fixes #517 🦕

The original intent of additionalMessage was to let users manually override the entire ReportedErrorEvent.message field. Which according to specs, must include the error message & stack trace in the format: errorMessage + "\n" + stacktrace. Additionally error message must be a string.

PR changes:

• renames additionalMessage param into customMessage param to be clearer about its intended use
• constrains customMessage param into only string, not object, type. As originally intended per original inline documentation:

* @param {String} [additionalMessage] - a string containing error message * information to override the builtin message given by an Error/Exception 

Tests passing.

Breaking or nonbreaking
I'm not sure whether to mark this PR as breaking or nonbreaking. Typically a change in an attr type warrants breaking but in this case, this attribute never worked, and is only introduced at the client lib layer...

[codecov]

Codecov Report

Merging #535 (a11fa9d) into master (ae63f68) will increase coverage by 0.01%.
The diff coverage is 95.00%.

@@ Coverage Diff @@ ## master #535 +/- ## ========================================== + Coverage 78.65% 78.67% +0.01%  ========================================== Files 23 23 Lines 3158 3160 +2 Branches 207 207 ========================================== + Hits 2484 2486 +2  Misses 671 671 Partials 3 3 

Impacted Files	Coverage Δ
src/index.ts	0.00% <0.00%> (ø)
src/interfaces/manual.ts	95.93% <100.00%> (+0.04%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ae63f68...a11fa9d. Read the comment docs.

[bcoe]

I'm not sure whether to mark this PR as breaking or nonbreaking. Typically a change in an attr type warrants breaking but in this case, this attribute never worked, and is only introduced at the client lib layer...

Am I following that this would been a noop if the user was attempting to set additionalMessage?

My only concern would be that we might break people who were attempting to set additionalMessage, next time they compile -- but, if we think that will be a relatively small number of people, I'm comfortable with the decision to call this a fix.

[freelerobot]

Will closely monitor this repo to see if folks have a lot of issues. I do think this affects a small number of people because this param isn't easily discoverable. It isn't documented unless folks dig into the code comments.

Though I am still wary since we don't have concrete usage numbers 😬