Add support for user defined attributes / manual overload resolution

Adds support for the following attributes on class methods:
* NoScript - Prevents the method from being registered.
* ScriptRename(newname) - Changes the method's registration name to newname (so if you had `A::foo @ScriptRename(bar)` it'd be registered as `A::bar`).
* ScriptAffix(affix, isSuffix) - Changes the method's registration name to include a prefix or suffix.

__Utility__
* Allows binding properties and other overloaded functions correctly, if the user specifies alternate function names.
* Allows the user to hide internal APIs (useful in games for example, where it might be beneficial to have access to renderer stats in Lua but without including the rest of the renderer's functions) with reduced boilerplate.

__Issues__
This still doesn't solve the base problem of registering overloaded functions and ideally pushMethod  and pushOverloadedMethod would be written with a more generic pushMethod as their base.

__Example__

```D
class A
{
	int _x = 10;

	int x() @property
	{
		return _x;
	}

	void x(int nx) @property @ScriptAffix("Set")
	{
		_x = nx;
	}

	void sayhello() @ScriptRename("hello")
	{
		writeln("hello");
	}

	void internalfunc() @NoScript
	{
		// ...
	}
}

A a = new A();
lua["a"] = a;

// In lua code
print(a:x()) // 10
a:Setx(2)
print(a:x()) // 2
// a:sayhello()  -- error, doesn't exist
a:hello() // "hello"
// a:internalfunc() -- error, doesn't exist
```
Just as boolean function parameters are usually bad design, I see this as equally bad. Upon seeing `@ScriptAffix("foo", true)` in source code, it's impossible to know what the boolean argument means without looking at the documentation, and even after the user has read the relevant documentation entry, it's hard to remember whether it means prefix or suffix. Using an enum is slightly more to type but results in perfectly clear code.