[Logs SDK] Rename and update existing LogRecord class, modify existing Recordable interface

[lalitb]

• To avoid conflict with the new LogRecord class, rename existing sdk::logs::LogRecord class to some better name (say sdk::logs::LogRecordData).
• Add setter for observed_timestamp in sdk:logs::Reordable and sdk::logs::LogRecordData.
• Similar to Span's Recordable, add a getter method for LogRecordData in Recordable class. This can be eventually implemented by all it's derived implementation (not in scope for now).

  /**
   * Get the LogRecordData object for this Recordable.
   *
   * @return LogRecordData*
   */

  virtual explicit operator LogRecordData *() const { return nullptr; }

This would let us avoid having ReadWriteLogRecord class. This method can be potentially used inside LogRecordProcessor to filter the logs based on it's contents (not in scope for now).

[owent]

Can we just rename it to ReadWriteLogRecord and just set data of Recordable from it?

// API:
namespace logs{
// prune class which only contains setters
class LogRecord;
}

//SDK
namespace sdk {
namespace logs{
// prune class which contains getters
class ReadableLogRecord : public logs::LogRecord;

// A replacement of legacy LogRecord
class ReadWriteLogRecord : public LogRecord;

class Recordable {
public:
  void SetLogRecord(const ReadableLogRecord & record) {
    SetTimestamp(record.GetTimestamp());
    SetSeverity(record.GetSeverity());
    SetBody(record.GetBody());
   // And etc.
  }

  virtual void SetTimestamp(opentelemetry::common::SystemTimestamp timestamp) noexcept = 0;
  virtual void SetSeverity(opentelemetry::logs::Severity severity) noexcept = 0;
  virtual void SetBody(nostd::string_view message) noexcept = 0;
  // etc.
};
}
}

How about this design? I think it's more simular to the relationship of trace span and recordable.

[lalitb]

@owent - Yes, that's look good too.