I am in a similar boat and have created my own "wishlist" as I've started calling it as it is hard to get buy-in from non-technical people. But I'll try to address each question.
1 - My first bit of advice is going to be upgrading the SQL instances to the same or similar version as far as the applications will allow. For us, that is mostly 2016, but it may be different for you. The instances that cannot be upgraded thankfully are managed outside of my hands so those ones (a 2000 and a 2005) are both isolated on their own machines tied heavily to the application and are both marked as EOL systems. So step 1 was to get a list of all instances, their versions and if they can be upgraded. If they cannot, then I needed to figure out if I actually owned and managed the systems and if not, they are outside the scope of the upgrade plan. Once they are all at the same version, maintenance becomes a lot more simple and if you decide to consolidate your instances, it is much safer if they are all on the same version.
2 - For software to manage the SQL Instances, SSMS has a built in "Registered Servers" which allows you to make a central management server for the SQL instances. That is what I use. Outside of SSMS, I use DxEnterprise for a failover tool which also (by design) shows me all of the instances and where they are hosted. DxEnterprise comes at a high price tag, but it is a very good failover tool (similar to HP Polyserve before it went EOL).
3 - For licensing, I would reach out to your licensing reseller as they will offer you the best advice based on the licenses you currently have. It may be different if you are a fully virtual environment, fully physical, or mixed too.
4\5 - For points 4 and 5, those are a lot bigger questions and I don't have good answers for that. It really depends on your system, how big your team is, what your timeline is, and the applications. For managing application data and report data, it depends on your systems and needs. If users are doing analytical reporting, then I'd recommend a data warehouse for that and load data in (ETL) as needed (may be nightly, may be weekly, may be yearly... I don't know your systems). For non-analytical reporting (ie real-time reporting), you likely will need to pull from the live systems. One big thing I'd advise against with reporting is don't mix the 2. If a report NEEDS real-time data (serial numbers in use) and CAN use some analytical data (internal part numbers), do it all from real-time.
For building the data dictionaries, that is a large undertaking itself.
If you have the budget for it, there are consultants you can hire in that will offer a lot better advice based on your specific system. In my case, I have 60-ish SQL instances with about 150 databases total. Some of the INSTANCES can be consolidated, SOME of the databases can be too. My approach is going to be to try to reduce the 60 instances down to about 5-10. Some of the instances will trivial to do this with as they are 3rd party applications and are all running the same SQL version. Downside is needing to be more fussy about permissions. I don't want 3rd party tool A having access to 3rd party tool B's data in any way. Things that will be tricky is our internal databases that we created which SHOULD be easier, but due to old, unmaintained, legacy code (VB6) that has little to no business benefit to update, changes to the databases needs to remain transparent to the software.
That is my advice anyways. A lot of those are tricky questions as it really depends on your specific situation and what your databases look like and how they are used. In your case, it may make more sense to install more instances and break the 250 databases out further.