feat(message): Add Flag Support

[jshlbrd]

Description

• Adds flag support to the message package
• Refactors condition package, transform package, and cmd apps for message flags

Motivation and Context

Recent releases have been opinionated about how to process data and we should move toward a future where there is less "internal magic" and things happening without user's being aware. This is most evident in how messages are skipped during data transformation if the accessed value is missing:

value := msg.GetValue(tf.conf.Object.SourceKey)
if !value.Exists() {
	return []*message.Message{msg}, nil
}

This might be the best choice for most use cases, but unless you know that lines like this exist, you have no idea this is happening. (There are some other examples of this as well, but this PR is focused on addressing message skips.) Message flags are foundational to fixing this problem because they make it possible to embed configs directly in messages, like this:

msg := message.New().SetData([]byte(demoEvt))
if skipNull {
	msg = msg.SkipNullValues()
}

if skipMissing {
	msg = msg.SkipMissingValues()
}

if skipEmpty {
	msg = msg.SkipEmptyValues()
}

Using flags, packages (condition, transform, etc.) can check for attributes like this:

if msg.HasFlag(message.SkipNullValues) && val.IsNull() {
	doSomething(msg)
}

This isn't a new concept because this is what the ctrl attribute already does for messages (except it was not created within a larger system of flags). These are now equivalent:

if msg.IsControl() {
	return []*message.Message{msg}, nil
}

if msg.HasFlag(message.IsControl) {
	return []*message.Message{msg}, nil
}

This PR is a feature and refactor to avoid a breaking change (missing values still cause a message skip for most transform functions), but in the future we will likely have a configuration that looks like this so that it's configurable by users:

{
  messages: {
    skip_missing_values: true,
    skip_empty_values: true,
  },
  transforms: [
    ...
  ]
}

How Has This Been Tested?

• All unit tests are passing.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[shellcromancer]

Style: It might be more clear that these are part of the flag system if their names are: FlagIsControl, FlagSkipNullValues, etc?

[jshlbrd]

I was avoiding stutter, like:

msg.HasFlag(message.FlagIsControl)

The Uber style guide has what looks like a good solution to this problem, so I added that.

[shellcromancer]

Is flags every a non int value from the iota above? If not, maybe this should have a stronger type than any.

[jshlbrd]

fixed