Add more debug context in places errors are generated

[2opremio]

Some host errors are not directly actionable. For instance:

         	            	Value: Status(HostStorageError(AccessToUnknownEntry))
        	            	
        	            	Backtrace (newest first):
        	            	   0: <unknown>
        	            	   1: soroban_env_host::storage::Storage::get
        	            	   2: soroban_env_host::host::data_helper::<impl soroban_env_host::host::Host>::load_account
        	            	   3: <unknown>
        	            	   4: <unknown>
        	            	   5: soroban_env_host::host::Host::invoke_function
        	            	   6: <unknown>
        	            	   7: preflight_host_function
        	            	   8: _cgo_3031edd0e0b1_Cfunc_preflight_host_function
        	            	   9: <unknown>

It indicates an entry is missing but it doesn't tell you which one, so that you can debug the problem further.

I suspect that's the case with many other errors.

It would help if we could add as much detail as possible to the error.

[leighmcculloch]

In this case I think we could get the additional details by outputting debug events in the host when looking up a storage item fails, attaching the debug event to the host error.

[2opremio]

Here's another (not very helpful) error:

Value: Status(HostAuthError(NotAuthorized))
        	            	
        	            	Backtrace (newest first):
        	            	   0: <unknown>
        	            	   1: <unknown>
        	            	   2: <unknown>
        	            	   3: <unknown>
        	            	   4: <unknown>
        	            	   5: <unknown>
        	            	   6: <unknown>
        	            	   7: <unknown>
        	            	   8: <unknown>
        	            	   9: <unknown>
        	            	  10: <unknown>
        	            	  11: <unknown>
        	            	  12: <unknown>
        	            	  13: <unknown>
        	            	  14: <unknown>
        	            	  15: <unknown>
        	            	  16: <unknown>
        	            	  17: <unknown>
        	            	  18: <unknown>
        	            	  19: <unknown>
        	            	  20: <unknown>
        	            	  21: <unknown>
        	            	  22: <unknown>
        	            	  23: <unknown>
        	            	  24: <unknown>
        	            	  25: <unknown>
        	            	  26: __libc_start_main
        	            	  27: <unknown>

It would be much more useful if we got a clear message indicating why it wasn't authorized and how to fix it

[graydon]

The plan here is actually to be making the errors a bit more coarse (i.e. less informative) but also to add more debug events, so that you get more information in the debug log while developing or running on an rpc server that's able to report debug events.

[graydon]

I think this was largely done in #806 -- feel free to file followups if you see cases where there isn't quite enough context still.