Change the set and unset ctlreqs by making the index argument optional.
This allows setting attributes on tables. One simply does not provide
an index in that case. Otherwise the entry corresponding the index has
the attribute set or unset.

Use this change to fix a relatively longstanding bug in our GPT scheme
that's the result of rev 198097 (relatively harmless) followed by rev
237057 (damaging). The damaging part being that our GPT scheme always
has the active flag set on the PMBR slice. This is in violation with
EFI. Existing EFI implementions for both x86 and ia64 reject the GPT.
As such, GPT disks created by us aren't usable under EFI because of
that.

After this change, GPT disks never have the active flag set on the PMBR
slice. In order to make the GPT disk bootable under some x86 BIOSes,
the reason of rev 198097, one must now set the active attribute on the
gpt table. The kernel will apply this to the PMBR slice For (S)ATA:
	gpart set -a active ada0

To fix an existing GPT disk that has the active flag set in the PMBR,
and that does not need the flag, use (again for (S)ATA):
	gpart unset -a active ada0

The EBR, MBR & PC98 schemes, which also impement at least 1 attribute,
now check to make sure the entry passed is valid. They do not have
attributes that apply to the table.
- The method introduced as part of r234898 for not altering the boot path
  when booting from ZFS turned out to also cause the boot path not being
  adjusted if booting from CD-ROM with firmware versions that do not employ
  the "cdrom" alias in that case. So shuffle the code around instead in order
  to achieve the original intent. Ideally, we shouldn't fiddle with the boot
  path when booting from UFS on a disk either; unfortunately, there doesn't
  seem to be an universal way of telling disks and CD-ROMs apart, though. [1]
- Use NULL instead of 0 for pointers.

PR:		179289
MFC after:	1 week
Add vfs_mounted and vfs_unmounted events so that components can be informed
about mount and unmount events. This is used by Juniper to implement a more
optimal implementation of NetBSD's veriexec.

Submitted by:	stevek@juniper.net
Obtained from:	Juniper Networks, Inc