Fix a pair of bugs in the gchandle code.

	* gc.c: Make sure pinned handles actually pin on sgen.
	* gc.c: Use gc_memmove and gc_bzero when dealing with memory
	that has managed references.
Add test for pinned gc handle.
Second attempt at Bug 5747 change: Deal with possible ending "/" this time.

My first fix for Bug 5747 was reverted because it broke something with
file system monitoring in XSP.

This is a revision of that same patch, but this time i take into account
the possibility that the fsw.FullPath value could possibly end with "/".
The previous version of this commit, no longer in place, didn't factor
that in and as a result if the fullpath ended in "/" we would cut the first
character off filename by virtue of the "Length + 1" substring.

The purpose of this patch was to fix the following problem:
files/directories modified in subdirectories were coming back with
just the file NAME and not subdirectory path.  This patch modifies
the filename so if you get an alert on a file in a subdirectory 'mysubdir/file1'
you would get 'mysubdir/file1' rather than just 'file1', for whatever
direcotry (fullpath) you are watching..

Please note, i tried but i can't get XSP from git to use my local development
version of mono -- as a result i couldn't test against XSP.  Instead, i tested
against the bug report source sample both with and without a trailing '/'
separator.  Prior to this revised version, if full pathname ended in a trailing
'/', and you modified 'file1' you would get back 'ile1' a as the filename if
the prior patch was applied.

Someone may want to test against xsp before accepting this revised submission
Implemented the .NET 4.0 generic versions of AccessRule and AuditRule.

Details worth being aware of, that aren't well documented in MS.NET:

(1) The Rights property is just a casted AccessMask.
I've checked this by testing with MS.NET -- if you use AccessRule<Test>
with an arbitrary struct Test { }, MS.NET has an InvalidCastException
on the Rights getter if you create with ObjectSecurity's factory method
(which is passed an int), and in the constructor if you use AccessRule's
constructor.

(2) The string constructor overloads call 'new NTAccount(identity)'.
What these methods do for AccessRule is not documented by MS.NET,
but this *is* documented for SemaphoreAccessRule, and my testing
with C# shows AccessRule does the same thing. So, I've implemented
this behavior to match.

I will submit a separate patch afterwards to make AuthorizationRule's
accept NTAccount, which is required for the string overloads to work.
Contrary to the MS.NET *documentation* (which Mono follows), AuthorizationRule
actually accepts NTAccount as well as (the documented) SecurityIdentifier.
I verified this by deriving a class from AuthorizationRule.
AuthorizationRule now accepts NTAccount like it should. Provided a unit test.

Many derived classes of AuthorizationRule have string overloads which pass
'new NTAccount (identity)'. The exception docs state "can be cast as a
SecurityIdentifier" not "is a SecurityIdentifier". Anyway, this fixes all the
string constructors in System.Security.AccessControl.

Also, I added checking for inheritanceFlags and propagationFlags parameters.

While building the unit test, I found accessMask == 0 throws ArgumentException,
not ArgumentOutOfRangeException, on MS.NET 4.0 (contrary to docs). So,
I've made this match.
Merge pull request #365 from JamesB7/system-security3

AuthorizationRule now accepts NTAccount like it should. Provided a unit test.
In KeventWatcher ProcessEvent we were passing null for changedFsi, incorrectly

We had a fsi value for changedFsi, but we were passnig null for it when
calling PostEvent.  This patch corrects that.
Whitespace fixes
Added unit test.

Also added constructors to ObjectSecurity<T>.
It's supposed to have them (they just pass to NativeObjectSecurity),
but the only user in Mono is MemoryMappedFileSecurity so this is
just for completeness's sake. Also, this lets the test depend on neither
System.Core nor internal methods.
Merge pull request #363 from JamesB7/system-security2

Implemented the .NET 4.0 generic versions of AccessRule and AuditRule.
MutexAccessRule... previously entirely broken as it passed 0 for accessMask.
Now, accessMask matches the MutexRules passed in. The MutexRules enum is a bitmask
corresponding to Win32 ACE accessMasks and the two match.

I verified that accessMask corresponds directly to the MutexRules passed in the
constructor on Win32 using Reflection. It stands to reason, and it turns out to be
the case. System.Security.AccessControl is still mostly broken but this at least
corrects MutexAccessRule.
Added a unit test for the bug this is fixing -- previously the constructor just crashed, always.
So, this constructs with valid MutexAccessRights, and also makes sure that the rights are correct.
Fixes a problem that was preventing mono from compiling

Somehow the compiler became more strict, and a not-implemented class is now
causing mono to fail to build.

The attached patch doesn't really fix anything besides letting it compile.

I was nice enough to throw a NotImplementedException() on the default
constructor.

The compile time error was:
System.IO.MemoryMappedFiles/MemoryMappedFileSecurity.cs(35,15): error CS0122:
`System.Security.AccessControl.ObjectSecurity
<System.IO.MemoryMappedFiles.MemoryMappedFileRights>.ObjectSecurity()' is
inaccessible due to its protection level

Feel free to reject this patch if I am the only one seeing this problem (on
Linux x86_64 build) after most recent git clone of mono/master.
Merge pull request #367 from robwilkens/work1

Fixes a problem that was preventing mono from compiling
Merge pull request #362 from JamesB7/system-security

Fix System.Security.AccessControl.MutexAccessRule's constructor.
Add missing attribute classes
Update corcompare
[sgen] Make heavy statistics compile again.
Merge branch 'master' of github.com:mono/mono
Make mkbundle bundle assemblies a lot faster.

Preallocate the 256 different lines we might write to the assembly file
instead of allocating several strings for every line.

With compression mkbundle is about twice as fast now (since compression
speed hasn't changed), without compression it's 5-10x faster, depending
on the number of assemblies to embed.