support interface for aas

Similar to class, we should allow interface. this will allow us to get to a goal where the ide will have increasing information about types.

interface would produce nothing in the brs code - the benefit of the type declaration would be entirely for the ide's symbol and definition resolution and the compiler.

example

interface styleInfo
  selectedColor: string
  color: string
  fontSize : integer
end struct

public function someMethod(buttonStyle: StyleInfo)
  button.applyStyle(styleInfo)
end function

output is

public function someMethod(buttonStyle: StyleInfo)
  button.applyStyle(buttonStyle)
end function

the interface would simply vanish at runtime; merely providing the ide with more type info. This does of course require that we have more advanced typing, which i would dearly love to see, whereby we can have as default values (object|integer|dynamic) as well as new specific types for our classes and interface (StyleInfo|MyButton|UserInfo|FancyButton), whereby the types here are the class or node names.

No files, tests, or entry points are named. Start by tracing how existing class declarations and type annotations are parsed and represented, then compare the compiler and IDE paths. Done means interface declarations provide the stated type information while producing no runtime BrightScript code, with coverage for the example syntax.