`goal` improvements: sessions

## Problem

Currently, running most `goal` commands requires that either the `--datadir` argument or the `ALGORAND_DATA` env var be set. The data directory is where important configurations that `goal` depends on are stored. For example, the URL of the local `algod` server is stored there.

However, many goal commands only interact via `algod` so do not need direct access to the data. Additionally, we can imagine use cases by which we want to connect to a different network, or remotely. For such cases, coupling node/network information, with goal configuration is an unnecessary complication.

## Solution

It is proposed that `goal` commands have an implicit `session`. The session stores all the data needed to successfully run `goal`. One idea is that the session be defined in a new `.goal.json` (or `*.yml`) residing in the directory where a `goal` command is being run, but an alternative would have all the session variables be stored as env vars. There should be an explicit way for users to manage their session. In particular:
* `goal session show` - to print out the current session variables
* `goal session set` - to be provided the opportunity set/reset all needed variables
* these could be passed as command line args `--datadir, --datanode, --algodurl` etc ...
* or when not provided, we could use a library such as [tview](https://github.com/rivo/tview) to ease configuration
* `goal session clear` - to unset the env vars / nullify values in `.goal.json` depending on the choice made for storing the session

## Implementation choices
1. There is a lightweight MVP version which introduces `.goal.json/yml` without a programmatic way to configure and lets a user override defaults when setting particular fields
2. If sessions are file based, we may want to deprecate the env var `ALGORAND_DATA`.
3. `goal session print` may make `goal algod info` obsolete (#5374)

## Dependencies

None

## Urgency

Medium - the current state of affairs which requires always providing `--datadir` or setting `ALGORAND_DATA` seems non-ideal. Additionally, future improvements (#5373, #5377) become more unwieldy without this.