Add Logs to the JavaScript SDK

[AbhiPrasad]

In #15442 we created an experimental logging API to test out the new logging product.

Based on the experimental API, we devised unified public API we'd like all SDKs to implement: https://www.notion.so/sentry/Logs-in-the-SDK-1a48b10e4b5d80b1827fe14d9fd0236b#1a48b10e4b5d80a782a9efc6fd463acf

This task looks at implementing this logging API in the JavaScript SDKs

• Define logs protocol and add log envelope types: feat(core): Add types for logs protocol and envelope #15530
• Implement log buffering and flushing logic on client: feat(core): Add captureLog method #15717
• Implement public API and flushing strategy for Browser feat(browser): Add logger.X methods to browser SDK #15763
• Implement public API and flushing strategy for Node.js feat(node): Add logging public APIs to Node SDKs #15764
• Add support for string parameterization in logging methods feat(core): Add support for parameterizing logs #15812
• Add beforeSendLog option and functionality feat(core): Add support for beforeSendLog #15814
• Add basic integration tests for browser test: Add browser integration tests for logs #15815

[AbhiPrasad]

After chatting with the team, we decided to go for an approach that does not add a new method to the client. This saves on bundle size, but does add some complexity around how internals and managed and exposed.

You can see both attempts here:

1. Adding method to client: feat(core): Add client.captureLog method #15715
2. Adding standalone captureLog: feat(core): Add captureLog method #15717

Pros and cons:

	Pros	Cons
Client Method	Logic is better encapsulated Matches other SDK implementations Easy access to client.flush() More easy for child classes (browser, server-runtime) to override functionality	Bundle Size increase of 1%-3% (!!!) Hard to change public API/method name without more bundle size cost
Standalone Method	Low bundle size hit Easier to rename or deprecate API	Need to expose internal methods to access log buffer data structure Don't match with other SDKs