Design for Warning functions

[jdunkerley]

As we are now using warnings more and more we need a couple of utility methods to handle them.

## Checks if any warnings (either all or of a specified type) are attached to the value.

   Arguments:
   - warning_type: The type to check if attached to the value. Defaults to any warning.
Any.has_warnings : Any -> Boolean
Any.has_warnings self warning_type=Any = ...

## Remove the warning s(either all or of a specified type) attached to the value.

   Arguments:
   - warning_type: The type to remove if attached to the value. Defaults to all warnings.
Any.remove_warnings : Any -> Any
Any.remove_warnings self warning_type=Any = ...

## Throws the first matching warning (either all or of a specified type) as a data flow error.

   Arguments:
   - warning_type: The type to throw if attached to the value. Defaults to all warnings.
Any.throw_on_warning : Any -> Any
Any.throw_on_warning self warning_type=Any = ...

What do people think?
cc: @radeusgd @GregoryTravis

[jdunkerley]

Some light design prior to tasking here - seem the correct place for smaller design discussions.
cc: @wdanilo @sylwiabr @NedHarding

[wdanilo]

The only question on my side is whether "throw warning" is a correct way to express the intention here. Would "attach_warning" not be better? "Throwing" in my head is connected with errors that stop the execution. Here we are attaching the warning to the dataflow. What do you think? Also clear_warnings could be named remove_warnings. Again, both names are correct, but I feel the later is more explicit regarding its behavior.

[jdunkerley]

Happy with remove_warnings.

Will rename throw_warnings to throw_on_warning - this function is not attach a warning but throw a dataflow error if a specific warning occured. For example, table.throw_on_warning Invalid_Format would raise the first invalid value from parse.

[radeusgd]

The design looks perfect to me.