Now supports multiple switches and multiple stacks. To do this, the existing
snmpit_cisco module had to be modified to behave as a true object, and its
interface changed.

A new layer of abstraction has been added: the stack. This is to hide the
details of how things such as VLAN creation occur across multiple devices. For
example, in Cisco stacks, you always contact the stack leader (VTP server) to
create/delete VLANs. Other switches may have different semantics, such as
having to contact every switch to create the VLAN.

Now uses libdb for database access and permissions checks.

Hardware details are hidden as much as possible in the user interface. For
example, the creation and deletion commands now take VLAN identifiers, and
snmpit transparently turns these into device-specific VLAN numbers.

snmpit.in has been re-written from scratch. The new version uses three basic
steps:
1) Process command line options and determine operation to run
2) Determine which devices, ports, and VLANs will be involved and make
   the appropriate objects
3) Actually perform the operation
   when TESTMODE is set, does only steps 1 and 2

Some command-line options have changed. This is because we now use getopt,
rather than a home-grown parser, to parse the command line. As a result of the
large number of options, and an attempt to mimic old options as much as
possible, the options are no longer very mnemonic.

Uses a new table called switch_stacks to figure out which switches belong to
which stacks. A stack is defined as a set of switches that share VLANs.

All snmpit scripts and modules now run with 'use strict' to help catch certain
programming errors.

VLAN listing now prints out the pid/eid and vname for VLANs, if possible.

A few things have bitrotted due to these changes:
* snmpit_intel will need to be re-tooled to use the new interface, and to
  behave as a proper object
* vlansync, vlandiff, and resetvlans depend on the output of snmpit, and will
  need to be updated to understand its new output format