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
```
I would use an empty struct here instead of a string. If say, PyD decided to use exactly the same method, there wouldn't be any way for the user to discriminate between Lua and Python scripts when marshalling the given method.

Also, clever uses of strings as attributes in other programs could lead to difficult-to-find bugs when used with LuaD:
```d
alias strings = TypeTuple!("foo", "NoScript", "bar"); // happens to contain the string "NoScript"

void foo() @(strings) // This function is now NoScript for LuaD
{
}
```
Using instances of structs is just more hygienic in general.