feat: migrate sdk-node away from getEnv(), introduce diagLogLevelFromString() util

[pichlermarc]

Which problem is this PR solving?

• Migrates away from getEnv() to the get*FromEnv() functions introduced in feat(core): add more scalable replacements for getEnv(), getEnvWithoutDefaults() #5443 @opentelemetry/sdk-node this is a pure refactoring and does not change behavior since that package is not used in the browser.
• Adds a utility to @opentelemetry/core to convert a string returned from getStringFromEnv() to a DiagLogLevel. This is what we can also use to replace the code in contrib and in the lambda wrapper.
  • getEnv().OTEL_LOG_LEVEL becomes stringToLogLevel(getStringFromEnv('OTEL_LOG_LEVEL))

Refs #5217

Type of change

• New feature (non-breaking change which adds functionality)
• refactor (sdk-node)

How Has This Been Tested?

• Unit tests

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.93%. Comparing base (60f2ce9) to head (5acb77e).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5475      +/-   ##
==========================================
+ Coverage   94.91%   94.93%   +0.02%     
==========================================
  Files         308      309       +1     
  Lines        7980     8002      +22     
  Branches     1682     1686       +4     
==========================================
+ Hits         7574     7597      +23     
+ Misses        406      405       -1     

Files with missing lines	Coverage Δ
...imental/packages/opentelemetry-sdk-node/src/sdk.ts	96.01% <100.00%> (-0.02%)	⬇️
...ental/packages/opentelemetry-sdk-node/src/utils.ts	92.03% <100.00%> (+0.65%)	⬆️
...ages/opentelemetry-core/src/utils/configuration.ts	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

[trentm]

Drive by review while this was still in draft.

[trentm]

Drive-by bikeshedding nit: Perhaps diagLogLevelFromString or getDiagLogLevelFromString?
Just a nit, however, so feel free to ignore this.

• diag in the name to differentiate these from the similar but different log severity values (

  opentelemetry-js/experimental/packages/api-logs/src/types/LogRecord.ts

  Lines 23 to 49 in 60f2ce9

  	export enum SeverityNumber {
  	UNSPECIFIED = 0,
  	TRACE = 1,
  	TRACE2 = 2,
  	TRACE3 = 3,
  	TRACE4 = 4,
  	DEBUG = 5,
  	DEBUG2 = 6,
  	DEBUG3 = 7,
  	DEBUG4 = 8,
  	INFO = 9,
  	INFO2 = 10,
  	INFO3 = 11,
  	INFO4 = 12,
  	WARN = 13,
  	WARN2 = 14,
  	WARN3 = 15,
  	WARN4 = 16,
  	ERROR = 17,
  	ERROR2 = 18,
  	ERROR3 = 19,
  	ERROR4 = 20,
  	FATAL = 21,
  	FATAL2 = 22,
  	FATAL3 = 23,
  	FATAL4 = 24,
  	}

  )
• aFromB or getAFromB naming to match some of the other similar API function names like getStringFromEnv. (Though to be fair bToA naming is used by "src/common/time.ts" exports like millisToHrTime. I'm an old timey fan of the aFromB naming per the ancient https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/) :)

[pichlermarc]

I like diagLogLevelFromString 🙂
Applied in 3a0a6c3

[trentm]

LGTM, modulo two small nits.