Preliminary support for Fortify import - Cleanup needed

This works similar to the Veracode import since we use the base class
for matching issues with tasks.

The Fortify mapping file is generated by an XSLT - run against a Fortify
rules file (with Internal and External category mapping). The present
implementation re-uses the same code. For instance the fortify mapping
file uses a category name; whereas the expectation was that it would be
a CWE-ID.

One important note is that the report id is not extracted from the
Fortify report. Since SD Elements does not presently have support for
'fortify' we use 'veracode' for the time being.
Use the  "Issue Count by Category" report section for issues
Fixed tool name
unnecessary line
Mapping refers to "weakness" now instead of "cwe", together with an associated type
Read the report name from the Fortify xml

Veracode is updated to use the new xml scheme
Confidence applied to Fortify mappings similar to Veracode

Grouped similar weaknesses under their shared task
Cleaned up fortify import code

Default import to record passes AND flaws (--flaws_only=False)
Added T193 to fortify mapping
Eliminated useless line in veracode test
Fixed T193 bug

Bug: Weaknesses used to be mapped to T193 and sent as project analysis
on-the-fly. This led to the problem where only the last unmapped
weakness would be displayed in the application.

Now we collect all unmapped tasks for T193 and then send them all at
once, as expected.
Findings are recorded and imported with a count, if possible

Instead of the base class assuming flaws are imported one-by-one, we can
now specify a 'count' of weaknesses.
Some exception handling added
breaking long lines a bit
Small spacing fix
Clarified task_exists method
Re-introduce formatting changes
Merge pull request #100 from sdelements/feature_import_fortify

all good