Food for thought: SymbolId can carry a pointer to the owning SymbolTable

SymbolId in itself is just a number and to resolve it _correctly_ it has to know which instance of SymbolTable it needs to use. This is very error prone and mistakes aren't very obvious. (I actually ended up introducing a bug and running the processes ended up creating files and directories in folders that were hard to get rid of because of special characters in them).

If SymbolId were to carry a pointer against which to resolve, it will eliminate lot of these issues. Basically, treating the SymbolId more like a _handle_ then as an _id_.

* Simplifies the API and usage of SymbolId and SymbolTable. Instead of `symbolTable->getSymbol(symbolId)` one would use `symbolId.value()`
* Avoids copying the same symbol into multiple SymbolTables. For instance, symbols from CompilerDesign's::SymbolTable gets copied to ErrorContainer::SymbolTable for reporting an error. Instead one would just add the SymbolId (and thus different symbols within the errors list could point to different instances of SymbolTable).

I can't envision a scenario where something like this would interfere with multithreading and/or multiprocessing since these are read operations and SymbolTable is guaranteeing location persistence.

@alaindargelas @hzeller Thoughts??

Start by locating the definitions and uses of SymbolId and SymbolTable, then trace how symbols are resolved and copied between CompilerDesign's::SymbolTable and ErrorContainer::SymbolTable. Determine the ownership and lifetime implications of making SymbolId a handle, including the stated multithreading and multiprocessing concerns. Done would require an agreed API design and coverage for resolution and error reporting.

Written by the indexing model from the issue text.