Error logging is lossy

setFailed(), error(), warning(), and notice() accept a string | Error but when an Error is passed, only its message is logged (through error.toString()). Users reading the workflow logs are thus missing a lot of valuable information to understand the problem. Especially when the error has a cause.

For instance, compare this when using setFailed(error):

Error: Error: Could not create installation access token.

to that when using console.error(error):

Error: Could not create installation access token.
    at fetchInstallationToken (file:///home/runner/work/github-app-token/github-app-token/dist/index.js:9:86699)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async file:///home/runner/work/github-app-token/github-app-token/dist/index.js:9:87634 {
  [cause]: RequestError [HttpError]: Not Found
      at file:///home/runner/work/github-app-token/github-app-token/dist/index.js:1:64438
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
      at async fetchInstallationToken (file:///home/runner/work/github-app-token/github-app-token/dist/index.js:9:86592)
      at async file:///home/runner/work/github-app-token/github-app-token/dist/index.js:9:87634 {
    status: 404,
    response: {
      url: 'https://api.github.com/app/installations/NaN/access_tokens',
      status: 404,
      headers: [Object],
      data: [Object]
    },
    request: {
      method: 'POST',
      url: 'https://api.github.com/app/installations/NaN/access_tokens',
      headers: [Object],
      request: [Object]
    }
  }
}

With the first logs, users have no way to understand what went wrong.
With the second ones, they could see that the URL contains NaN instead of a number.

You could argue that debug(error) should be used instead to provide detailed error reporting when rerunning the failed job with debug logging enabled but its signature is debug(message: string) so instances of Error are not accepted. Even if they were, I think it's a better UX to log errors clearly/fully by default. Maybe the error is flaky and won't occur again when rerunning the job with debug logging enabled.

Describe the enhancement

Since @actions/core expose debug(), info(), error(), warning(), notice() helpers, it would be nice if users could use them without missing out on the good error reporting offered by the corresponding console functions (e.g. console.error()).

Code Snippet

Calling setFailed(error), error(error), warning(error), or notice(error) logs error clearly/fully instead of just error.toString().

Additional information

Tested with @actions/core 1.10.0.

Locate the TypeScript implementations of setFailed(), error(), warning(), and notice(), then inspect how Error arguments are currently converted and where their behavior is tested. Done means these helpers preserve the full error information, including stack details and causes, instead of logging only error.toString().