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
```
Personally, I think it should be separated into @ScriptPrefix("pre") and @ScriptSuffix("post"), it's possible that they may both want to appear, and it eliminated the second piece of data.

Perhaps a nitpick, but I don't see precedent for PascalCase in this case, it should be @scriptPrefix like every other attribute.
I also don't see any reason for 'script', I think the pseudo-namespace is implicit in that the attribute symbol is defined inside LuaD.
If the intent was for clarity, then I think @luaPrefix() would make it a lot clearer to me.

I was going to add this same feature to my fork shortly too.