scan session id now available when session cleanup is deferred

[kevinrr888]

Previously, when a scan session was attempted to be cleaned up but couldn't and was deferred for later, the scan session id would still be visible from things like the listscans command but would have a value of -1. This change:

• makes it so that the session id is still available in this situation
• improves logging related to scan session ids and logs the scan session ids in more places
• tests that invalid (0 = never set, -1 = no longer tracking) scan session ids are no longer seen

TODOs from issue

• [x] Modify Session class to track session id
• [x] Update all log messages in SessionManager to include the session id
  • most logs were just printing the Session so just added the id to the toString()
• [x] Modify list scans code to ensure session id always shows up. It currently stops showing up for sessions being cleaned up.
• [x] Test that scan session id is always present in list scans.
• [x] Improve log messages added in adds metric to count zombie scans #4840 to include scan session id.
  • no changes needed here, covered by addition of the session id to Session.toString()
• [x] Survey log messages related to scans in server and client for places where the scan session id could be included in the log message.
  • Surveyed some classes of interest
    • TabletClientHandler
      • Considered from its use of Session objects, but there is no use of ScanSessions so N/A
    • ThriftScanner
      • Added scan id to one log, but the rest of the class seemed to log the scan id when needed
    • ScanServer
      • A couple log changes, but the rest of the class looked good
    • ThriftScanClientHandler
      • A couple log changes here, but most of the other methods (e.g., startScan()) I did not think needed log messages since adding them here would cause them to be logged twice with how ScanServer uses this class

closes #4842