Idea: Alias shared members with Imports

I mentioned this in #103, but it probably deserves its own discussion. I'm not 100% convinced it's a good idea (hence idea instead of a full proposal); there's probably a reason this wasn't implemented before.

# The Idea
Use the existing ```Imports``` alias syntax (```Imports alias = type```) to import shared members (methods, properties, fields, etc.) in addition to types. This would work for both the ```Imports``` statement and imports declared in the project file.

It might mesh well with #162 (Method-scoped Imports).

## Examples
```VB
Imports Print = System.Console.WriteLine
Imports Sqr = System.Math.Sqrt
```

# Possible Use Cases
- Possible way of implementing #103. I can imagine setting up aliases for Print in the in-box project templates, so a new console application could call something like ```Print("Hello, World")``` and it would work.
- Source compatibility with renamed methods. VB6 had Sqr and .NET has Sqrt, for example.

Any others?

# What About Instance Members?
```VB
Imports Print = Foo.WriteLine
Dim Foo As FooClass
Print("Hello, World!")
```
This code would throw a null reference exception on ```Print("Hello, World!")```, where the fact that there is a reference that could be null is hidden. (Maybe there are workarounds to better tie the exception to the Imports statement and the underlying reference without complicating debugging.)

Also, how would you get the instance to invoke the method?
```VB
Imports Print = System.IO.File.AppendText("foo.txt").WriteLine
```
Would every ```Print``` call after this secretly create a new FileStream object? (Maybe the answer to this is just documentation.)

At this point, it's also starting to look a little like macros in disguise. It looks safer to just allow shared members.

Any other thoughts? Does this look like worthwhile at all? Is there a case for any member, or should it be limited to methods?