runtime type checking operator

The BrightScript runtime has multiple different ways a primitive can be stored as a variable. So checking for something like "is this a 32bit int" requires mulitple checks. We should add a brighterscript operator that simplifies the logic for those patterns.

We would check them like this:

function bslib_isBoolean(val as dynamic)
    ' the `type` call is expensive, so lift into a local var first
    valType = type(val)
    return valType = "Boolean" or valType = "roBoolean"
end function

Primitive items:
This is probably the most helpful, as we can check for multiple type output values at once.

someBoolean is Boolean   ' transpiles to bslib_isBoolean(type(someBoolean))
someInt32 is Integer     ' transpiles to bslib_isInteger(type(someInt32))
someInt64 is LongInteger ' transpiles to bslib_isLongInteger(type(someInt64))
someFloat is Float       ' transpiles to bslib_isFloat(type(someFloat))
someDouble is Double     ' transpiles to bslib_isDouble(type(someDouble))
someString is String     ' transpiles to bslib_isString(type(someString))

Composite types
We could include another nice one for "anything numeric" which would check for int32, int64, float, and double.

someNumber is Number ' transpiles to bslib_isNumber(type(someNumber))

BrightScript components
This could also work for all the other component types. Here are a few examples:

someArray is roArray       ' transpiles to type(someArray)) = "roArray"
someRegexp is roRegex      ' transpiles to type(someRegexp) = "roRegex"
someDateTime is roDateTime ' transpiles to type(someDateTime) = "roDateTime"

Start by tracing how BrightScript operators are parsed and transpiled, then review the existing runtime bslib helpers and type handling. Compare the proposed primitive, Number, and component cases with current conventions. Done means the operator behavior is implemented and verified for the listed examples.